PCX 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




oiNT^NA-nONAL APPUCATION PUBUSHED UNDER THE PATENT COOPERA TION TOEATY (PCT) 
(51) International Patent Classification ^ 



(11) International Publication Number: WO 98/1036 

(43) InteraaUonal Publication Date: 12 Match 1998 (12.03.98) 



(21) International Application Number: PCT/US97/ 15492 

(22) International FUing Date: 4 September 1997 (04.09.97) 



(30) Priority Data: 
08/707.660 
08/889,319 



4 September 1 996 (04.09,96) US 
8 July 1997 (08.07.97) US 



(71) Applicant: WALKER ASSET MANAGEMENT LIMITCD 

PARTNERSHIP [USAJSJ; Five High RidM Park, Stamford 
CT 06905 (US). 

(72) Inventors: WALKER, Jay. 124 Spectacle Lane. Ridge- 

field, CT 06877 (US). SCHNEIER, Bruce; 101 E, Min- 
nehaha Parkway. Minneapolis. MN 55419 (US). SPARICO. 
Thomas. M.; 115 Lockwood Road. Riverside. CT 06878 
(US). CASE, T., Scott; 29 Anthony Unc, Daricn, CT 
06820 (US). JORASCH. James. A.; Apartment 5G. 25 For- 
est Strecu Stamford, CT 06901 (US). VAN LUCHENE. 
Andrew. S,; I3-2a Clarmorc Drive. Norwalk, CT 06850 
(US). TEDESCO. Daniel. E.; 88 Bam Hill Road, Mon- 
roe. CT 06468 (US). JINDAU Sanjay. K.; 52 Village 
Walk. Wilton, CT 06897 (US). WEIR-JONES, Toby; 3A 65 
Prospect Street. Stamfonl. CT 06901 (US). LECH, Robert 
R.; 3 Valley View Drive #25. Norwalk. CT 06851 (US) 



(74) Agwits: HUGHES, Chris. A. et al.; Morgan & Finncgan 
L.L.P.. 345 Park Avenue, New York. NY 10154 (US). ' 

(81) Designated States: AL, AM. AT. AT (Utility model). AU, A2. 
BA. BB, EG, BR, BY. CA, CH, CN, CU. CZ. CZ (Um^ 
modd). DE. DE (Utility model). DK, DK (Utility model) 
EE^ EE (Utility model), ES. FI, FI (Urility model), GB, GE. 
GH, HU. IL. IS. JP, KE. KG. KP, KR. K2. LC. LK. lJ 
^ MX. NO. NZ, 

c^ ^ .S?' SI, SK. SK (Utility modeO^ 

SU TJ, pi, TR. rr. UA. UG, U2, VN. YU, ZW, ARIPO 
patent (GH, KE. LS. MW, SD. SZ. UG. ZW), Eurasian 
patent (AM. AZ. BY. KG. KZ. MD, RU, TJ. TM), European 

f??" »i^'i:n®^"- ^- ™« GB. grTi^ 

LU, MC, NL. PT. SE). OAPI patent (BF, BJ. CP CG a 
CM, GA, GN. ML. MR, NE. SN. TD, TG). ' * 

Published 

With intemationat search reporu 

Before the ejqfiraiion of the time limit for amending the 
claims and to be repubUshed in the event of the receipt of 
amendments, T 



(54) Tide: CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEMS 




(57) Abstract 



The present invention is a method and apparatus for cffectuatiiiff bilateral VmtMWTM^m^ 



FOR THE PURFOSBS OF INFORMATWN ONLY 
Codes used to identify States party to Uie PCT on the fnmt pages of pamphlets publishing international applications under the PCT. 



AL 


Albnii 


ES 




LS 


Lciocho 


SI 


Stovenia 


AM 


Armenia 


n 


FrotaDd 


LT 


Lithuania 


SK 


Sbmlua 


AT 


Austrii 


PR 


Prance 


LU 


Loxembouig 


SN 


Senegal 


AU 


Auitnhft 


OA 


Gabon 


LV 


Ljtvia 


sz 


Swaziland 


AZ 


AzerlMijui 


GB 


United Kiitfdom 


MC 


Monaco 


TD 


Chad 


BA 


Bocnia nd Hmegovfaia 


GE 


GecKiia 


MD 


RqxMic of Moldova 


TC 


Togo 


BB 


BHtados 


6H 


Ghana 


MG 


Madagaacar 


TJ 


TMlciKaD 


BE 


Belfiuro 


GN 


Goinea 


MK 


The former Yo^otltv 


TM 


"nHfcrncnietan 


BP 


Baridnt I^so 


GR 


Offwoe 




Repoblic oT Macedonia 


TR 


Turkey 


BG 


Bti]g«ria 


HU 


Hungary 


ML 


MaU 


TT 


Trinidad and TbbiVO 


B] 


Benin 


IE 


IielaBd 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Beluw 


IS 


Iceland 


MW 


Malawi 


US 


United States o( America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


UzbeUAan 


CP 


Cencrel Afiricm Rqmblic 


JP 


Japtn 


NE 


Niger 


VN 


Viet Nam 


CG 


COQgO 


KE 


Kenya 


NL 


Neiheriands 


YU 


Yugoafayia 


CH 


SwiixertKid 


KG 


Kyigyzstan 


NO 


Norway 


ZW 


Zimbaibwe 


a 


CO(e d'lvoin 


KP 


Democmic I^eople't 


NZ 


New Zealand 






CM 


CimcToon 




Repttttic ofKoica 


PL 


Poland 






CN 


Chhka 


ICR 


ReiwblicorKoica 


FT 


Portng^ 






CU 


Cotw 


KZ 


Kazriutan 


RO 


Romania 






CZ 




LC 


Saint Lnda 


RU 


Rutsian HederatioB 






DK 


Ocnnaiy 


U 




SD 


SodM 






DK 
EE 


Deanuik 
Rftonia 


LK 
LR 


SriUnka 
Liberia 


SR 
SG 


Svndeo 
Singapore 







WO9aa0361 



PCT/US97/1S492 



CONDITIONAL PURCHASE OFFER MANAGEMENT SYSTEMS 

Field of the Invention 

The present invention relates to a method and apparatus for processing 
5 the sale of products using electronic networks to customers who have submitted an offer 
for the purchase of such products. 

Background of the Invention 

Most systems for processing the sale of products are seller-driven. 

10 whereby the seller prices, packages and configures the product, and the buyer decides 
whether or not to accept. Traditionally, the seller must attract buyers and complete the 
sale. Thus, in a seller-driven system, the advertising cost of the transaction and the 
attendant risks that such advertising will be unsuccessful falls upon the seller. 

Typically, goods and services are sold in a retail environment using a 

15 seller-driven protocol, whereby the seller generally sets a non-negotiable price that the 
buyer may accept or reject. Other forms of conunerce provide more flexibility and 
permit the exchange of offers and counteroffers. In an auction, for example, the buyer 
does not find the seller, rather the seller attracts numerous buyers who collectively 
determine the final selling price, which the seller may subsequently reject unless the 

20 item auctioned is being sold without a reserve. Other commerce systems, such as 
NASDAQ or the New York Stock Exchange (NYSE), are exchange-driven, where 
buyers and sellers are matched by offering an efficient, fair and orderly marketplace. 
Such exchange-driven systems favor neither buyers nor sellers, but simply effectuate 
communications that allow for the matching process to take place. An example of an 

25 automated exchange-driven conunerce system for trading futures is disclosed in United 
States Patent Number 4.903,201 . 

A buyer-driven system, on the other hand, is one where the buyer 
dictates the terms of the offer and the seller decides whether or not to accept. A "help 
wanted" advertisement, for example, is a buyer-driven inquiry since the employer is 

30 looking to locate and buy the services of a qualified employee. The inquiry is 
advertised to a large number of potential employees, who may respond by submitting 
their resumes to the prospective employer. Generally, buyer-driven systems are more 
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p.^ferable than other systems for processing the sale of p,t,ducts. For example buyer- 
dnven systems provide buyers with more control over the terms and conditions of d,e 
purchase of a desit^d product. Additionally, when a large number of potential sellers 
exist, but those sellers do not have the re«,urces to advertise globally, buyers can take 
the miuauve to communicate their needs to the sellers. 

Unilateral buyer-driven systems seek to consummate contracts between 
buyers and sellers based on acceptance of an offer by perfonr,ance of a designated task 
For example, in a reward system, a "buyer" broadcasts or publishes an offer for a 
reward to anyone who completes a particular task. Thus, unilateral systems can be 
utilized only for limited types of transactions that allow for acceptance by performance 
Bilateral buyer-driven systems, on the other hand, seek to consummate contracts 
between buyers and sellers based on mutual p^mises to perform. Bilateral buyer- 
dnven systems, however, require buyers to invest a lot of time, money and other 
f^urccs to locate an indefinite number of potential sellers and communicate the 
.5 buyer's purchasing needs to each seller. Any benefits to the consumer with 
conventional bilateral buyer-driven systems, however, including a potentially lower 
pnce. ^ typically outweighed by the amount of time and money expended in the effort 
In addmon. buyer-driven systems impose inherent costs on sellers as well If each 
buyer has a different set of purchasing specifications and communicates his needs using 
20 non-umform language, sellers must pay a substantial cost to «.view and understand each 
individual request. Mo^over. sellers are often not amenable to customizing their 
products for individual buyers. 

An example of a regularly used bilateral buyer-driven process is the 
system utilized by large organizations, such as companies or governments, who want to 

25 purchase significant amounts of goods or services at the lowest possible price. Initially 
purchasers formulate a detailed written specification, typically called a "Request for 
Proposal" (RFP). setting forth the quantities and requirements of what they are looking 
to buy. Or.ce finalized, the RFPs are then distributed to a list of known potential 
suppliers. Potential suppliers then scieen the RFPs to identify those that they might be 

30 able to fulfill, and thereafter determine whether or not to invest the necessary time and 
effort to submit a formal binding proposal to the buyer by a deadline established in the 
RFP. Once submitted, the proposals are evaluated by the buyer, and the supplier 
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corresponding to the selected proposal is notified that it has "won" the business at the 
price quoted. 

Large organizations can take advantage of the benefits afforded by the 
RFP process because their volume buying represents a worthwhile opportunity for 
5 suppliers to compete for their business and large organizations have the resources to 
communicate their buying needs to a sufficient number of suppliers. As a result, large 
organizations can often achieve substantial unit cost savings, especially on commodities 
or commodity services (such as paper clips or long distance service) and on perishable 
items (such as airline tickets and hotel rooms). Individual consumers, however, cannot 
10 effectively participate in such bilateral buyer-driven systems because they generally do 
not have the buying power and resources of large organizations. 

As commerce seeks to utilize the inherent advantages of the Internet, 
many systems for processing the sale of products, such as malls, catalogs and auctipn 
houses, are being implemented on the Internet. These approaches generally seek to 
15 create better seller or exchange-driven systems whereby the sale of goods and services 
is made more efficient. While diere have been some attempts to use the Internet to 
effectuate bilateral buyer-driven transactions, those attempts have been largely 
unsuccessful. For example, buyers can post "wanted" advertising at little or no cost on 
"bulletin board" type Internet sites. Thus, consumers can essentially post their own RFP 
to a large number of sellers willing to sell them the exact product they are looking for. 
In practice, however, it is impractical for potenUal sellers to frequent the various 
'bulletin board" sites or respond to the individual RFPs which typically have diverse 
formats, conditions, terms, and language styles. In addition, sellers are deterred from 
using such a process because there is (i) no guarantee of the authenticity of the RFP, (ii) 
25 the cost of negotiating with individual consumers is often too high, and (iii) it is difficult 
to enforce any agreement (including payment guarantees) which may be reached 
between the consumer and the seller. In turn, the absence of a critical ma-ss of sellers 
reduces the incentive for buyers to post their RFPs. 

Many industries, as well as consumers, would benefit from an effective 
30 bilateral buyer-driven system. Recently, for example, the travel industry has 
experienced explosive worldwide growth. As travel capacity continues to increase, it is 
expected that capacity will outpace projected traveler volumes, thereby reducing 
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utilization and putting pressure on pricing. In order to deal with such pricing and 
inventory challenges, many travel-related seller, have developed sophisticated revenue 
management systems (RMSs) to optimize revenue by dynamically setting the price for 
available inventory. Generally, when inventory is first added by a seller, the seller's 
5 revenue management system attempts to maximize revenue for the inventory by 
establishing a plurality of price classes and then allocating the inventory and price 
assrgned to each price class. The revenue management system thereafter continues to 
momtor the actual demand within each price class relative to forecasted demand 
dynamically reevaluating the inventory allocation and pricing of each price class for 
10 given inventory. 

While conventional revenue management systems employ sophisticated 
tools to anticipate future travel needs, forecasting errx,n. invariably lead to unanticipated 
excess capacicy. ,„ addition, a seller can utilize its revenue management sy.s.em to 
forecast anticipated excess capacity, such as excess capacity on a given flight associated 
15 with seats that are predicted to be empty. Furthermore, unexpected external events 
such as a pnce war or extreme weather conditions, can also affect a seller's excess 
capacity. TTrus, in an attempt to reduce such excess capacity, seller, periodically 
reevaluate the inventory allocation and pricing. Travel-related sellers cannot simply 
discount the published prices for such unsold inventory, however, without either starting 
10 a pnce war or compromising their own underiying price structure (i.e.. without also 
reducmg its full-fare prices for full-fare travelers). Thus, there is currently no effective 
way for travel-related sellers to dispose of such excess capacity. 

Travel-related sellers recognize that there is a large source of latent 
demand a.ssociated with leisure travelers who are willing to travel at a favorable price 
^ There is currently no effective way, however, for such sellers to receive an offer from a 
buyer for leisure travel at a particular price set by the buyer, below the seller's published 
pnce. In particular, there is no effective way for the seller to be confident that if the 
seller accepts the buyer's offer, the buyer will travel in accordance with the offer 
without using the information to ascertain the seller's underiying level of price 
0 nexibility, which, if known to a seller's competitors or buyers, could dramatically 
impact the seller's overall revenue structure. 
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Similarly, with the long distance telephone market becoming nearly 
saturated with supply, competition among long distance carriers for new business has 
increased dramatically. Although the costs associated with long distance calls have 
dropped and arc expected to continue dropping dramatically in the United States and 
other countries as the result of increased competition, the cost of a long distance call 
remains sufficiently high to discourage many people from placing as many long 
distance calls as they would like. In addition, most callers are typically unfamiliar with 
the rate structure associated with placing calls to various geographical areas at various 
times of day. Thus, the inability to identify and control the cost of a long distance call 
has further contributed to the reluctance of many people to place more long distance 
calls. 

While many large customers, such as corporate customers, often have 
sufficient leverage to negotiate their long distance rates with a long distance carrier, or 
to permit carriers to bid for their account, it is impractical, given current telephone 
systems, for long distance providers to individually negoUate long distance rates with 
the average consumer. In addiUon. many large customers have accounts with a number 
of different long distance carriers, and employ "least cost routing" technology in their 
proprietary private branch exchange (PBX) switches or other customer-premises 
equipment. This technology enables them to select the most cost-effective carrier on a 
20 per-call basis using stored rate information. Again, such a cost-reduction solution is not 
available to the average consumer, who typically has only one long distance provider. 
While systems have been developed to allow consumers to identify a long distance 
carrier offering the most cost-effective published rate to complete a call, such systems 
do not facilitate real-time negotiation with individual carriers, or permit one or more 
25 telephone calls to be completed in accordance with restrictions specified by the calling 
party. 

In addition, conventional commerce systems limit the ability of resellers 
of tickets for events, such as a concert, play or sporting event, to advertise ticket 
availability and complete a ticket transaction. Currently, ticket resellers may utilize 
30 classified advertisements, electronic bulletin boards or "chat rooms" on the Internet to 
advertise ticket availability. Such advertisements are difficult to remove from the 
public realm once the tickets are resold. Thus, a pereon selling a ticket may get 
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inquiries after the ticket has been sold. In addition, the buyer requires physical 
possession of the actual ticket, and delivery immediately prior to the event may be 
pmblemauc. Furthermore, buyers and sellen, of tickets possess a general distrust of 
each other. Unless a buyer is face-to-face with a ticket „.seller. the buyer is typically 
unwdhng to pay for tickets without some assurance of delivery. Likewise, a ticket 
reseller is typically unwilling to deliver tickets without payment in advance 
Conventional ticket ^.selling systems, however, do not provide any mechanism for 
guaranteemg the authenticity of either the buyer or the .seller. 

In addition to the above-described drawbacks of known commerce 
systems, seller, often require information relevant to a buyer's offer from a third party 
m order to determine whether to accept the offer. For example, potential buyers of 
artworks require that the artworks be accompanied by a tmsted thinl party's "seal of 
approval." Such a seal would typically authenticate that the artworks are genuine and 
also appraise their value. Similarly, potential lenders of funds requin. the cn^it history 
or a "credit score" of a potential borrower. Lenders would typically not accept such 
cnt.cal mformation from die potential borrower, since the borrower might try to alter 
the mformauon to appear more credit-worthy. The credit information must come from a 
trusted third party. 

Accordingly, an offer to borrow funds, which would include borrower- 
specified conditions, such as an interest rate and loan amount, would by itself be 
insufficient for the lender to determine whether to accept the offer. Potential lenders 
would not be able to ascertain whether the offer was acceptable in terms of credit risk 
and credit worthiness. Thus, buyers would not be able to usefully make such offers 
Current systems for evaluating borrower credit risks in connection with the sale of 
financial products, such as the system disclosed in United States Patent Number 
5.611,052. do not permit potential borrowers to specify desired loan conditions In 
addition, the system disclosed in United States Patent Number 5.611.052 does not 
prevent people who do not intend to buy from inundating a seller of financial products 
with worthless loan applications. 

As apparent from the above deficiencies with conventional systems for 
processing the sale of products, a need exists for a bilate... buyer-driven system 
capable of being utilized by individual consumers to communicate their purchasing 
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needs globally to potential sellers, which addresses the deficiencies of the prior art. A 
further need exists for a bilateral buyer-driven system which authenticates the terms and 
conditions of buyer offers. There is also a need for third party administration in such a 
bilateral buyer-driven system to resolve contract disputes between the parties, increase 
5 buyer and seller confidence in the system and establish standard protocols, formats, 
terms and language to be used in buyer-specified offers. A further need exists for a 
system that permits a seller to sell excess capacity when actual demand fails to meet 
forecasted demand. Another need exists for a buyer-driven system that permits a buyer 
to obtain products at a price set by the buyer, typically below the published price of the 
10 product. Yet another need exists for a system that permits sellers to stimulate sales of 
excess inventory or capacity, without compromising the seller's published price 
structure. Finally, there is a further need for a system that allows sellers to evaluate the 
acceptability of an offer from a buyer in light of information relevant to the offer from a 
third party. 

15 

Summary of the Invention 

A conditional purchase offer (CPO) management system for 
consummating a binding contract between a remote prospective buyer and a remote 
potential seller is disclosed, including a memory device, and a processor disposed in 

20 communication with the memory device, the processor configured to receive from the 
remote prospective buyer (a) a purchase offer containing at least one condition, and (b) 
a payment identifier for specifying a general purpose financial account from which 
funds may be paid for a purchase meeting the at least one condition, the processor 
further configured to transmit the purchase offer to a plurality of remote potential 

25 sellers, and receive from at least one of the remote potential sellers an unconditional 
acceptance of the offer. In one embodiment of the invention, the processor is further 
configured to initiate the use of the payment identifier to effect payment for the 
purchase from the buyer, and the general purpose financial account is a credit card 
account. In various embodiments of the invention, the at least one condition may be 

30 selected from the group consisting of price, quantity, delivery date, quality, geographic 
location, and anonymity. 
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A system according to another embodiment of the present invention that 
penn.ts the CPO management system to accept or reject a given CPO on behalf of 
certain agency-based sellers who have delegated such authority to the CPO management 
system, is disclosed, including a communications port and a processor The 
5 communications port obtains a purchase offer for travel from a customer and receives 
one or more rules f^m a plurality of sellers. The purcha.se offer contains at least one 
customer-defined condition and each of the rules contains one or more seller-defined 
lestncuons. The processor compares the purchase offer to the nrles to detemiine 
whether the customer-defined condiUon satisfies each of the seller-defined restrictions 
10 of at least one of the rules. 

In one embodiment, if a CPO is accepted by more than one seller the 
CPO management system executes a post-sell multi-bind process to permit each 

acceptmg seller to directly market to the customer and post-sell their product Thus the 
customer still selects for himself which seller acceptance to utilize, based on materials 
.5 or mcentives furnished by each seller. The customer is bound by the CPO management 
system, m accordance with the terms of the CPO. and is obligated to purchase the goods 
or services specified by the CPO. but the buyer may decide which seller to utilize based 
on matenals or incentives provided to the customer directiy by each accepting seller. 

A CPO submitted by a customer can specify one or more preferred 
20 sellers. Thus, the CPO management system provides the CPO to each specified seller to 
detennme if one or more of the sellers are willing to accept the CPO. In a supplemental 
embodiment, the CPO management system preferably executes an excluded seller CPO 
evaluation process to provide the CPO to the excluded sellers who may make 
counteroffers to the customer, in an attempt to obtain the business, before one of the 
^ specified sellers accepts ti.e CPO. The CPO can be provided to ti,e excluded sellers 
before, or contemporaneously with, the preferred sellers. 

A system according to another embodimem of the present invention 
suitable for processing the sale of packages of goods and semces. is disclosed' 
.ncludmg a communications pon and a processor. The communications port receives a 
0 purchase offer for a package from a customer. TT^e purchase offer contains a 
descnptron of each component item and a payment identifier for specifying a general- 
purpose account from which funds may be paid. The processor deconstructs the 
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package purchase offer into a plurality of component purchase offers and determines if 
each of the component purchase offers are accepted by one or more potential sellers. 
The customer is thereby bound to purchase the package if an acceptance is received for 
each of the component purchase offers. 

A system according to another embodiment of the present invention, 
suitable for processing purchase offers for one or more telephone calls, is disclosed, 
including a communications port and a processor. The communications port obtains a 
purchase offer from a customer for one or more telephone calls and provides ihe 
purchase offer to a plurality of potential carriers. The purchase offer contains at least one 
customer-defined condition and a payment identifier for specifying a manner in which 
funds will be paid. The processor determines if one or more of the carriers accepts the 
purchase offer and binds the customer to purchase the telephone calls if an acceptance is 
received for the purchase offer. 

A method according to another preferred embodiment of the present 
invention suitable for reselling event tickets includes: a potential buyer electronically 
transmitting a guaranteed purchase offer for a ticket to a central controller; the central 
controller electronically making the offer available to a plurality of potential sellers; a 
first-accepting seller transmitting an acceptance of the offer to the central controller; and 
the central controller transmitting this acceptance to the buyer along with a code to use 
at a venue to verify his purchase of the ticket 

Thus, one preferred embodiment of the prc.sent invention provides 
individuals a quick and easy way to purchase a ticket from a ticket reseller, and allows 
them to avoid the traditional problems of the ticket resale market. Moreover, ticket 
resellers can sell a Ucket based on a guaranteed purchase offer provided by a potential 
buyer. In addition, the present invention includes mechanisms which prevent fraud both 
during and after the transaction. 

Generally, according to a further embodiment of the present invention, 
that permits sellers to evaluate the acceptability of an offer from a buyer in light of 
information relevant to the offer from a third party, a central controller receives an offer 
signal including at least one condition signal. The offer signal defines a conditional 
purchase offer having at least one condition from a customer. The central controller 
also receives a payment identifier signal for specifying an account from which funds 
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may be paid. An informational signal relevant to the offer is received from a third 
party. The informational signal typically includes relevant information that would 
be trusted if it came from the borrower submitting tiie conditional purchase offer. 

A more complete understanding of the present invention, as well a? 
furtiicr features and advantages of the present invention, will be obtained by reference 
the following detailed description and drawings. 



not 

as 
to 



Brief Des cription of the Drawinfjs 

Figure I illustrates a first embodiment of die present invention. 

Figure 2 is a block diagram showing one embodiment of the central 

controller. 

Figure 3 is a block diagram showing one embodiment of the seller 

interface. 

Figure 4 is a block diagram showing one embodiment of the buyer 

interface. 

Figure 5 illustrates an embodiment showing how a conditional purchase 
offer is generated. 

Figure 6 illustrates an embodiment showing the acceptance of a 
conditional purchase offer by the central controller. 

Figure 7 illustrates an embodiment showing the activation of a 
conditional purchase offer. 

Figure 8 illustrates one embodiment of die maintenance of active 
conditional purchase offers. 

Figure 9 illustrates an embodiment showing Uic seller selecting a 
conditional purchase offer. 

Figures 10 and 11 illustrate an embodiment showing the binding of a 
conditional purchase offer. 

Figure 12 illustrates an exemplary procedure for exchanging goods and 
payment between buyer and seller. 

Figure 13 illustrates an exemplary payment method. 
Figures 14 Uirough 17 illustrate an exemplary authentication procedure 
using cryptographic protocols. 
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Figures 18 and 19 illustrate an exemplary embodiment for counteroffers 

by a seller. 

Figure 20 illustrates an embodiment showing the use of a trusted server 
and a bonding agency. 

5 Figure 21 is a schematic block diagram illustrating a conditional 

purchase offer (CPO) management system in accordance with one embodiment of the 
present invention. 

Figure 22 is a schematic block diagram of the exemplary CPO 
management central server of Figure 21, 

10 Figure 23 is a schematic block diagram of the exemplary secured airline 

server of Figure 21. 

Figure 24 is a schematic block diagram of the exemplary central 
reservation system of Figure 2 1 . 

Figure 25a is a schematic block diagram of the exemplary reservation 
1 5 management system (RMS) of Figure 2 1 . 

Figure 25b illustrates the interaction between the RMS, the airline 
reservation system and the various databases depicted in Figure 25a, during a 
conventional pricing and allocation process and the CPO rules generation process of 
Figure 39. 

2^ Figure 25c illustrates the actual demand over time for airline tickets 

within a given fare class, relative to forecasted demand. 

Figure 26 illustrates a sample table from the customer database of Figure 

22. 

Figure 27 illustrates a sample table from the airiine database of Figure 

25 22. 

Figure 28 illustrates a sample table from the flight schedule database of 
Figures 22 and 24. 

Figures 29a and 29b, collectively, illustrate a sample table from the CPO 
database of Figure 22. 

Rgure 30a illustrates a sample table from the secured airiines rules 
database of Figure 23. 
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Figures 30b and 30c, collectively, illustrate alternative sample tables to 
the secured airlines rules database of Rgure 23. 

Figure 31 illustrates a sample table from the counteroffer rules database 

of Figure 23. 

Figure 32 illustrates a sample table from the secured airline audit 
database of Figure 23. 

Figure 33 illustrates a sample table from the pricing and restrictions 
database of Figures 24 and 25a. 

Figure 34 illustrates a sample table from the seat allocation database of 
Figures 24 and 25a. 

Figure 35 illustrates a sample table from the forecast and demand 
analysis database of Figure 25a. 

Figures 36a through 36c. collectively, are a flov. chart describing an 
exemplary CPO management process implemented by the CPO management central 
server of Figure 22. 

Figures 37a and 37b. collectively, are a flowchart describing an 
exemplary evaluation process implemented by the secured airiine server of Figure 23. 

Figure 38 is a flow chart describing an exemplary audit process 
implemented by the secured airiine server of Figure 23. 

Figure 39 is a flow chart describing an exemplary CPO rule generation 
process implemented by the revenue management system of Figure 25a. 

Figures 40a and 40b, collectively, illustrate an alternative sample table 
from the CPO database of Figure 22 for a cruise implementation. 

Figure 41 illustrates an alternative sample table from the secured rules 
database of Figure 23 for a cruise implementation. 

Figure 42 is a flow chart describing an exemplary post-sell multi-bind 
precess which may be implemented by the CPO management central server of Figure 
22. 

Figure 43 illustrates a sample table from the excluded operator 
counteroffer database which may be implemented by the CPO management central 
server of Figure 22 in conjunction with the flow chart of Figures 44a and 44b. 
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Figures 44a and 44b, collectively, are a flow chart describing 
exemplary excluded seller CPO evaluauon process which may be implemented by the 
CPO management central server of Figure 22. 

Figure 45 is a schematic block diagram illustrating a package 
conditional purchase offer (CPO) management system in accordance with one 
embodiment of the present invention. 

Figure 46 is a schematic block diagram of the exemplary central 
controller of Figure 45. 

Figure 47 is a schemaUc block diagram of the exemplary secured server 

of Figure 45. 

Figure 48 is a schematic block diagram of an exemplary buyer or seller 
interface of Figure 45. 

Figure 49 illustrates a sample table from the buyer database of Figure 46. 
Figure 50 illustrates a sample table from the seller database of Figure 46. 
Figure 51 illustrates a sample table from the package CPO database of 



Figure 52 illustrates a sample table from the component CPO database of 
Figure 53 illustrates a sample table from the market price database of 



Figure 46. 
Figure 46. 
Figure 46. 

Figures 54a and 54b illustrate sample tables from the secured seller rules 
database of Figure 47. 

Figures 55a through 55c. collectively, arc a flow chart describing an 
exemplary package CPO posting process implemented by the central controller of 
Figure 46. 

Figures 56a through 56c. collectively, are a flowchart describing an 
exemplary package CPO monitoring process implemented by the central controller of 
Figure 46. 

Figure 57 is a flow chart describing an exemplary component CPO rule 
evaluation process implemented by the secured server of Figure 47. 
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Figure 58A is a schematic block diagram illustrating a conditional 
purchase offer (CPO) management system in accordance with one embodiment of the 

present invention. 

Figure 58B » a schcmalic block diagram illusmdng a condiUonal 
po-chas. offer (CPO) n^^^ s,«em in accortance „irt a„ al«.a.. cmbodimen, 

of the present invention. 

Figure 59 is a perspective view of an illustrative telephone set utilized by 
the callmg party of Figures 58A or 58B. 

Figure 60 is a schematic block diagram of a central server used by the 
CPO management system of Figure 58. 

Figure 61 illustrates a sample table from the customer database of Figure 

60. 

Figure 62 illustrates a sample table from the carrier database of Figure 
Figure 63 illustrates a sample table from the published rate database of 

Figure 60. 

Figure 64 illustrates a sample table from the CPO database of Figure 60 
figures 65a and 65b. collectively, are a flow chart describing an 

exemplary CPO managemem process implemented by the centnU server of Figure 60 

Figures 66a and 66b. collectively, are a flow chart describing an 

exemplary IVRU process implemented by the central server of Figure 60. 

Figure 67 is a schematic view of a system accoiding to one embodiment 
of the present invention. 

Figure 68 is a schematic view of a central controller used in the system 

of Figure 67. 

Figure 69 is a schematic view of a remote user terminal used in the 
system of Figure 67. 

Figure 70 is a schemauc view of a venue controller used in the system of 

Figure 67. 

Figure 71a is a table illustrating the contents of an event table used in the 
system of Figure 67. 
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Figure 71b is a table illustrating the contents of a venue table used in the 
system of Figure 67. 

Figure 71c is a table illustrating the contents of a customer table used in 
the system of Figure 67. 

Figure 71d is a table illustrating the contents of an offer table used in the 
system of Figure 67. 

Figure 7!e is a table illustrating the contents of a transaction table used 
in the system of Figure 67. 

Figure 72a is a table illustrating the contents of a ticket table used in the 
system of figure 67. 

Figure 72b is a table illustrating tiie contents of a replacement ticket table 
used in the system of figure 67. 

Figures 73a-73g are flow diagrams depicting a method of submitting and 
accepting a guaranteed offer to buy an event ticket over the Internet according to one 
embodiment of the present invention. 

Figure 74 is a schematic illustration of a system for processing the sale of 
products provided in accordance with the present invention. 

Figure 75a is a schematic illustration of an embodiment of a central 
controller of the system of Figure 74. 

Figure 75b is a schematic illustration of another embodiment of a central 
controller of the system of Figure 74. 

Figure 76 is a schematic illustration of a borrower database of the central 
controller of Figures 75a and 75b. 

Figure 77 is a schematic illustration of a lender database of the central 
controller of Figures 75a and 75b. 

Figure 78 is a schematic illustration of an offer database of the central 
controller of Figures 75a and 75b. 

Figure 79 is a schematic illustration of a credit report database of the 
central controller of Figures 75a and 75b. 

Figure 80 is a schematic illustration of a collateral database of the central 
controller of Figures 75a and 75b. 
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Figure 81a is a schematic illustration of a response database of the 
central controller of Figure 75a. 

Figure 81b is a schematic illustration of a rule database of the central 
controller of Figure 75b. 

Figures 82a and 82b are flowcharts showing a method for processing 
sales of a loan between a borrower terminal and lender terminals. 

Figure 82c is a flowchart showing another method for processing sales of 
a loan between a borrower terminal and lender terminals. 

Detailed Descrintinii nf Preferrpd Rmbodimente 

The method and apparatus of one embodiment of the present invention 
will now be discussed with reference to Figures I. 2. 3. and 4. In a preferred 
embodiment, the present invention includes central controller 200, seller interface 300, 
buyer interface 400, and associated databases. The present invention receives 
conditional purchase offers from buyers, makes them available for viewing by potential 
sellers, and allows sellers to bind them. Thus, a buyer is able to communicate his 
commitment to follow through on an offer to a seller, giving the seller confidence that if 
he can produce the goods, the buyer has the ready edacity to pay. 

SYSTEM ARCHITECTURE 

The system architecture of a first embodiment of the apparatus and 
method of the present invention is illustrated with reference to Figures 1 through 4. As 
shown in Figure 1. the apparatus of the present invention comprises seller interface 300. 
central controller 200. and buyer interface 400 (collectively the "nodes"). Each node is 
connected via an Internet connection using a public switched phone network, such as 
those provided by a local or regional telephone operating company. Connection may 
also be provided by dedicated data lines, cellular. Personal Communication Systems 
("PCS"), microwave, or satellite networks. Seller interface 300 and buyer interface 400 
are the input and output gateways for communications with central controller 200. 

Using the above components, the present invention provides a method 
and apparatus to post conditional purchase offers, make them available to potential 
sellers, and allow sellers to bind the offers to form a legally binding contract. 
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As shown in Figure 2, central controller 200 includes central processor 
(CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, 
clock 235, operating system 240, network interface 245;and data storage device 250. 

A conventional personal computer or computer workstation with 
5 sufficient memory and processing capability may be used as central controller 200. In 
one embodiment it operates as a web server, both receiving and transmitting CPOs 100 
generated by buyers. Central controller 200 must be capable of high volume transaction 
processing, performing a significant number of mathematical calculations in processing 
communications and database searches. A Pentium microprocessor such as the 100 
10 MHz P54C, commonly manufactured by Intel Inc., may be used for CPU 205. This 
processor employs a 32-bit architecture. Equivalent processors include the Motorola 
120 MHz PowerPC 604 or Sun Microsystem's 166 MHz UltraSPARC-I. 

An MC68HC16 microcontroller, commonly manufactured by Motorola 
Inc., may be used for cryptographic processor 210. Equivalent processors may also be 
15 used. This microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 
16 MHz configuration and requires less than one second to perform a 512-bit RSA 
private key operation. Cryptographic processor 210 supports the authentication of 
communications from both buyers and sellers, as well as allowing for anonymous 
transactions. Cryptographic processor 210 may also be configure as part of CPU 205. 
20 Other commercially available specialized cryptographic processors include VLSI 
Technology's 33MHz 6868 or Semaphore Communications' 40 MHz Roadrunner284. 

Referring again to Figure 2, payment processor 230 comprises 
conventional microprocessors (such as the Intel Pentium), supporting the transfer and 
exchange of payments, charges, or debits, attendant to the method of the apparatus. 
25 Payment processor 230 may also be configured as part of CPU 205. Processing of 
credit card transactions by payment processor 230 may be supported with cormnercially 
available software, such as the Secure Webserver manufactured by Open Market, Inc. 
This server software transmits credit card numbers electronically over the Internet to 
servers located at the Open Market headquarters where card verification and processing 
30 is handled. Their Integrated Commerce Service provides back-office services necessary 
to run Web-based businesses. Services include on-line account statements, order-taking 
and credit card payment authorization, credit card settlement, automated sales tax 
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calculations, digital receipt generation, account-based purciiase tracking, and payment 
aggregation for low-priced services. 

Data storage device 250 may include hard disk magnetic or optical 
storage units, as well as CD-ROM drives or flash memory. Data storage device 250 
5 contains databases used in the processing of transactions in the present invention 
including buyer database 255. seller database 260, CPO database 265, counteroffer 
database 267. seller response database 270. purchase confirmation database 275 
contract detail database 280, payment database 285. cryptographic key database 290 
and audit database 295. In a preferred embodimem database .software such as OracIe7 
.0 manufactured by Oracle Corporation, is used to create and manage these databases' 
Data storage device 250 also stores information pertaining to buyer account 297. seller 
account 298, and escrow account 299. 

Buyer database 255 maintains data on buyers with fields such as name 
address, credit card number, phone number. ID number, social security number 
15 electronic mail address, credit history, past system usage, public/private key 
information, etc. This information is obtained when the buyer fir.t register, with the 
system, or immediately prior to posting his first CPO 100. Buyer database 255 also 
contains the tracking number of each CPO 100 generated by the buyer, and the tracking 
number of each seller response 1 10 and counteroffer 140 directed to the buyer's CPOs 



20 100. 



Seller database 260 maintains data on sellers with fields such as name 
contact informaUon. public/private key information, payment preferences type of 
business, and goods sold. Contact information comprises a phone number, web page 
URL, bulletin board address, pager number, telephone number, electronic mail address 
25 vo.ce mail address, facsimile number, or any other way to contact the seller Upon 
.egistration. the seller may be required to demonstrate evidence of ability to deliver on 
bound CPOs 100. An airiine. for example, might submit a listing of the city pairs they 
service so that central controller 200 can quickly determine whether the airline is 
capable of satisfying a given CPO 100. 

30 CPO database 265 tracks all CPOs 100 with fields such as status 

tracking number, date. time, subject, price, expiration date, conditions, and buyer 
Identification number. This database is valuable in the event of disputes between buyers 
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and sellers regarding payment, because details of the contract can be produced. CPO 
database 265 may also store bond certificate 172. 

Counteroffer database 267 tracks all counteroffers 140. The structure of 
this database is identical to CPO database 265. except for the addition of a field for CPO 
tracking number that allows counteroffer 140 to be correlated with a particular CPO 
100. 

Seller response database 270 tracks all seller responses 1 10 with fields 
such as seller name, seller ID number, date, Ume. seller response tracking number, and 
associated CPO tracking number. 

Purchase confiimation database 275 tracks the messages sent to the 
buyer and seller confirming completed transactions (bound contracts). Fields include 
buyer name, buyer ID number, seller name, seller ID number, purchase confirmation 
tracking number, and associated CPO tracking number. 

Contract detail database 280 contains form background provisions for 
inclusion in CPOs 100. These form provisions effectively fill the gaps between 
conditions specified by the buyer, specifying the generic contract details common to 
most CPOs 100. 

Payment database 285 tracks all payments made by the buyers with 
fields such as buyer name, buyer ID number, amoum of payment, and associated CPO 
tracking number. This database may also store credit card numbers of buyers. 

Cryptographic key database 290 facilitates cryptographic functions, 
storing both symmetric and asymmetric keys. These keys are used by cryptographic 
processor 210 for encrypting and decrypting CPOs 100. seller responses 1 10, purchase 
confirmations 120. counteroffers 140, and buyer responses 150. 

Audit database 295 stores transactional information relating to the 
posting of CPOs 100. allowing it to be retrieved for later analysis. 

Buyer account 297 tracks all information pertaining to the buyer's 
account with fields such as buyer's name, bank and credit account numbers, and debit or 
credit transactions. This account may be a pointer to account data stoied at the buyer's 



30 bank. 
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Seller account 298 tracks all infonnation pertaining to the seller's 
account with fields such as seller's name, bank and credit account numbers, and debit or 
credu transactions. Buyer payments for CPOs 100 may be sent to this account. 

Escrow account 299 is an account that temporarily holds buyer funds 
before they are placed in seller account 298. 

Network interface 245 is the gateway to communicate with buyers and 
sellers through respective buyer interface 400 and seller interface 300. Conventional 
mtemal or external modems may serve as network interface 245. Network interface 245 
supports modems at a range of baud rates from 1200 upward, but may combine such 
mputs into a T, or T3 line if more bandwidth is required. In a preferred embodimem 
network interface 245 is connected with the Internet and/or any of the commercial on- 
hne services such a.s America Online, CompuSen^e, or Prodigy, allowing buyer, and 
sellen. access from a wide range of on-line connections. Several commercial electronic 
ma.1 server, include the above functionality. NCD Software manufactures 
PosLOffice," a secure server-based electronic mail software package designed to link 
people and information over enterprise networks and the mtemet. The product is 
platform independent and utilizes open standards based on Internet protocols Users can 
exchange messages with enclosures such as files, graphics, video and audio The 
system also supports multiple languages. Alternatively, network interface 245 may be 
configured as a voice mail interface, web site. BBS. or electronic mail address. 

While the above embodiment describes a single computer acting as 
central controller 200, those skilled in the art will realize that the functionality can be 
distributed over a plurality of computers. In one embodiment, central controller 200 is 
configured in a distributed architecture, wherein the databases and processors are 
housed in separate units or locauom.. Some controller, perform the primary processing 
functions and contain at a minimum RAM. ROM. and a general processor. Each of 
these cont^llers is attached to a WAN hub that serves as the primary communication 
hnk with the other controller, and interface devices. The WAN hub may have minimal 
processing capability itself, serving primarily as a communications router Those 
skilled m the art will appreciate that an almost unlimited number of controllers may be 
supported. This arrangement yields a mo,^ dynamic and flexible system, less prone to 
catastrophic hardware failures affecting the entire .system. The trusted server 
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embodiment provides more details of such a distributed environment, describing 
operations server 160. trusted server 165. and bonding agency 170. The hardware of 
these servers would be configured similarly to that described for central controller 200. 

Figures 3 and 4 describe seller interface 300 and buyer interface 400. 
respectively. In an exemplary embodiment they are both conventional personal 
computers having an input device, such as a keyboard, mouse, or conventional voice 
recognition software package; a display device, such as a video monitor; a processing 
device such as a CPU; and a network interface such as a modem. THese devices 
interface with central controller 200. Alternatively, seller interface 300 and buyer 
interface 400 may also be voice mail systems, or other electronic or voice 
communicaUons systems. As will be described further in the following embodiments, 
devices such as fax machines or pagers are also suitable interface devices. 

Referring now to Figure 3. there is described seller interface 300 which 
includes central processor (CPU) 305. RAM 315. ROM 320. clock 335, video driver 
325. video monitor 330. communicaUon port 340. input device 345, modem 350, and 
data storage device 360. Cryptographic processor 335 and biometric device 355 may be 
added for stronger authentication as described later. A Pentium microprocessor such as 
the 1 00 MHz P54C described above may be used for CPU 305. Clock 335 is a standard 
chip-based clock which can serve to timestamp seller response 1 10 or counteroffer 140 
produced with seller interface 300. 

Modem 350 may not require high-speed data transfer if most seller 
responses 1 10 and counteroffen: 140 produced are text-based and not too long. If a 
cryptographic processor is required, the MC68HCI6 miciocontit)ller described above is 
used. The structure of biometric device 355 will be described below in conjunction 
with the cryptographic authentication embodiment. 

Data storage device 360 is a conventional magnetic-based hard disk 
storage unit such as those manufactured by Conner Peripherals. Message database 370 
may be used for archiving seller responses 110 and counteroffers 140. while audit 
databa.se 380 may be used for recording paymem records and communications with 
central controller 200. 

Referring now to Figure 4, there is described buyer interface 400 which 
includes central processor (CPU) 405. RAM 415. ROM 420. clock 435. video driver 
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425, video monitor 430. cryptographic processor 435, communication port 440, input 
device 445, modem 450, and data storage device 460. AH of these components may be 
identical to those described in Figure 3. 

There are many commercial software applications that can enable the 
communicaUons required by seller interface 300 or buyer interface 400. the primary 
functionality being message creation and transmission. Eudora Pro manufactured by 
Qualcoram Incorporated, for example, provides editing tools for the creation of 
messages as well as the communications tools to route the message to the appropriate 
electronic address. When central controller 200 is configured as a web server, 
conventional communications software such as the Netscape navigator web browser 
from Netscape Corporation may also be used. The buyer and seller may use the 
Netscape Navigator browser to transmit CPO 100, seller response 110 or counteroffers 
140. No proprietary software is required. 

ONLINE EMBODIMENT 
In one embodiment of the present invention, communications between 
buyers and sellers take place via electronic networks, with central controller 200 acting 
as a web server. The buyer logs on to central controller 200. creates CPO 100. and then 
disconnects firom the network. CPO 100 is made available to potential buyers by 
posting CPO 100 on the web page of central controller 200. Periodic maintenance is 
performed by central controller 200 to ensure that active CPOs 100 have not expired, 
and that the buyer has sufficient credit available to pay a seller who elects to bind CPO 
100. Seller responses 1 10 are transmitted electronically to central controller 200 which 
contacts the buyer to indicate that CPO 100 has been bound. Central controller 200 
transfers credit card information to the seller as soon as CPO 100 is bound. 

With reference to Figure 5. there is described the process by which the 
buyer formulates CPO 100. At step 500. the buyer logs on to central controller 200 
using buyer modem 450 of buyer interface 400. establishing a communication link. It 
should be noted that the buyer may be an individual, a corporation, a parUiership, a 
government, or any other entity. In one embodimem, central controller 200 has a page 
on the World Wide Web, allowing the buyer to provide information through the 
interface of conventional web browser software such as Netscape Navigator, 
manufacnired by Netscape. Inc. At step 510. the buyer selects the subject of the goods 
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he wants to purchase by selecting from a list of possible subjects. As shown in box 5 1 5. 
subjects might include airline tickets, hotel rooms, rental cars, insurance, mortgages, 
clothing, etc. After the subject is selected, a form is displayed on video monitor 430 of 
buyer interface 400. This form is an electronic contract with a number of blanks to be 
filled out by the buyer, with each blank representing a condition of CPO 100. 

At step 520. the buyer enters a description of the goods. A business 
traveler, for example, might want to fly from San Francisco to New York. The 
description of the goods might be two first class round-trip tickets between those city 
pairs, leaving May 7 and returning May 12. There would be a place on the form for 
originating city, destination city, date of departure, date of return, number of tickets, 
class of service, etc. The buyer simply fills in the blanks. The buyer then adds other 
conditions at step 530. The buyer, for example, may only want a nonstop ticket on a 
flight arriving at the destination city before midnight. These conditions would be 
similarly entered into CPO 100. As indicated in box 535, conditions could include the 
provision that a flight must arrive before midnight, a hotel rx)om must be non-smoking, 
or a rental car must not be a compact. Conditions are the terms of CPO 100, allowing 
the buyer to tailor CPO 100 for his specific needs. Conditions may also be based on 
other conditions. For example, one condition might state that four out of five other 
specified conditions must be met. AltemaUvely, each condition of CPO 100 could be 
given a point value, with CPO 100 requiring only that conditions be satisfied up to a 
certain total point value. For example, the buyer may indicate that a window seat is 
worth two points, an aisle seat one point, and a nonstop flight four points, etc. CPO 100 
could require that ten "points" must be met in order to satisfy the conditions of CPO 
100. Conditions could also indicate Uiat for twenty-four hours following the first 
attempted binding of CPO 100, other sellers may make offers to bind, with the original 
binding seller completing the contract only if no better offer has been received. 
Conditions could even be based on external events. For example, die buyer could create 
CPO 100 which offered to buy airiine tickets only in the event dial it was snowing in 
November in the destination city. 

At step 540, the buyer adds an expiration date to CPO 100, if desired. 
This allows a buyer to post CPO 100 without worrying that he will later be bound after 
his needs have changed. At step 550, the buyer enters a price. In a CPO 100 for a 
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rental car. for example, the buyer may enter a price of Hfty dollars for a three-day rental 
At step 560. the buyer attaches his name or a unique user ID number to CPO 100 This 
ID number is received from central controller 200 when the buyer registen. for the 
serv.ce. or is chosen by the buyer and then n^gistet^d with central controller 200 by 
phone. Central controller 200 maintains a database of buyer ID numbers in buyer 
database 255, and issues (or allows) only unique numbers. If less security is ..quired 
the user's telephone number could serve as the ID number since it has the advantages of 
be.ng both unique and easily remember^. If additional security is required those 
procedures described in the cryptographic embodiment may be implemented. 

Once the above elements have been developed, the buyer transmits them 
to central controller 200 at step 570. The buyer docs this by clicking on a "send" button 
located on the screen in which he entered the terms of CPO 100. At step 580 
boilerplate legal language is added to the components of CPO 100 to fonn a complete 
CPO 100. The legal language is pulled from contract detail database 280 that stores a 
plurality of paragraphs. These paragraphs are linked together with the above contract 
elements to form a complete CPO 100. The only element missing which pn^vents CPO 
100 from being recognized as a legitimate contract is the name and signature of the 
seller. 

Instead of a Worid Wide Web-based interface, buyen; may also transmit 
CPO 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions 
W,th vo.ce mail, the buyer calls central controller 200 and leaves CPO 100 in audio 
form. These CPOs 100 may be transcribed into digital text at central controller 200 or 
made available to potential sellers in the same audio format. In a postal mail 
embodrment. central controller 200 acts more like a router, directing CPOs 100 to the 
potential sellers, creating multiple copies of CPO 100 if necessary. CPO 100 may also 
be posted to bulletin boards or web pages operated by central controller 200. Central 
controller 200 supports a plurality of transmission methods, allowing for a wide variety 
of formats of CPOs 100. Some formats may be changed, however, before further 
pn)cessing by central controller 200. CPOs 100 transmitted by mail in paper fom. for 
example, may be scanned-in and digitized, using optical character recognition software 
to create digital text. These embodiments are more fully described in the off-line 
embodiment described later. 
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Referring now to Figure 6, CPO 100 is received and checked to see that 
sufficient credit is available to cover the stated price of CPO 100. before CPO 100 is 
made available to potential sellers. At step 600. central controller 200 extracts price and 
expiration date information from CPO 100. At step 610, payment processor 230 
5 submits a pre-authorization of the price of CPO 100 to the credit card clearinghouse. 
This serves to "lock up" a portion of the available credit on the buyer's credit card, 
preventing him from using up this credit while CPO 100 is still active. At step 620. the 
credit card clearinghouse responds to the pre-authorization. indicating whether 
sufficient credit is available. If sufficient funds are not available to cover the price of 

10 CPO 100. another credit card number is requested from the buyer at step 630. Once an 
additional credit card number has been transmitted, central controller 200 then 
resubmits the pre-authorization at step 610. At step 640, the expiration date of CPO 100 
is checked to see if it has already expired. If it has expired, CPO 100 is rejected at step 
650 and returned to the buyer. If CPO 100 has not yet expired, it is accepted at step 

15 660. 

Referring now to Figure 7. there is illustrated an embodiment in which 
CPO 100 is activated and made available to potential sellers. At step 700, a unique 
tracking number is added to CPO 100. Central controller timestamps CPO 100 at step 
710, and then stores CPO 100 in CPO database 265. CPO database 265 contains a 

20 record for each CPO 100. and includes fields such as status, subject, tracking number, 
timestamp, description of goods, price, expiration date, conditions, and buyer ID 
number. The status field has values of "pending," "active." "expired," and "completed." 
A status of "pending" means that the CPO is not currcnUy available to potential sellers. 
Either it is still being processed by central conm>ller 200, or it has been temporarily 

25 suspended by the buyer. An "active" CPO 100 is available to potential sellers and can 
be bound. An "expired" CPO 100 can no longer be bound. CPOs 100 that have been 
bound by a seller have a status of "completed." 

After being stored at step 720, CPO 100 may go through a series of 
processing steps. One step, if necessary, is language translation, either creating a 

30 standard language that all CPO 100s must be written in, or translating to the language 
most appropriate for the sellers to which it will be sent. This translation is provided by 
language experts at central controller 200. or by automatic translation software such as 
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Systran Professional, manufactured by Systran Softwan.. Twelve bi-directional 
language combinaUons are available, including English .o/f«,ni Ft.nch Italian 
German. Spanish. Portuguese, and Japanese. Another step, if necessary, is to edit fo^ 
spelhng or grammatical errors. CPO 100 might also be n^viewed for clarity Any CPO 
100 w.th an unclear term or condition would be returned to the buyer for clarification 
A buyer listing a destination city of "Chicago" might have CPO .00 .turned for 
Clarification or correction. 

R.f«ri„g again „ Flg„„ 7. ^ ^ ^ 
.00 se, ,0 -aaive- « «.p 730. A, s«p 740. ,he sabjec, of CPO ,00 c,^ 
subject fleld. A. 750. CPO ,00 is ^ i„ ^ ,„,j„, ^ 

c™,.„„ 200 ,0 display CPO ,00 only ,„ .h. ™„s, app„,,ia,e .e|,e„ 
■n a World Wide Web environmen,. cenW com™,lc, 200 has a web page for «ch 
poss* subjea area TTus all CPOs 100 aiHine .ickct, „«.,d be displayed 

on .he airline Ucke, web page. Uis „.kes i, „„ch easier for po«„,ial sellers ,0 Hnd 
W^priau, CPOs 100 U.e, „.gb, >™„ u, bind as .hey can go Hgb, ,„ d» wh»e 
goods d«y can provide, m an al«„,a,ive embodiment. CPO 100 is electr»,icll, 
m«led ,0 potential sellers, either individually or in gr™^. Potential sellers could elect 
«. receive all CPOs 100. only those CPOs ,00 in their subject arc^ or a subset of CPOs 

100 representing a particular condition For (.xamnu , 

wuiiuiuon. por example, a car rental company might 

request that all car rental CPOs 100 for luxury cars be sent to them. 

In an embodiment in which CPOs 100 a,^ being transmitted to the seller 
.MS .mportant to note that there are a number of hardware options for seller interface' 
300. Suitable seller interfaces 300 include fax machines, persona, digital assistants 
(PDAs) with wireless connections, and beepers or pagers. For example, a rare coin 
dealer could instruct centra, controller 200 to beep him whenever CPO 100 appear^ for 
Morgan Silver Dollars, providing details of CPO ,00 over the beeper network or 
.nformmg the seller to log on to central controller 200 for further details. 

Referring now to Figure 8. there is illustrated a procedure for the 
n^ntenance of CPOs 100. At step 800. centra controller 200 searches CPO database 
265. At step 810. U,e expiration date field of each database record of CPO 100 is 
compared to the current date. If the expiration date of CPO ,00 is earlier than the 
current date, the status of CPO 100 is changed to "expired" at step 820. At step 830 



26 



WO9W10361 PCT/US97/1S492 

payment processor 230 contacts credit card clearinghouse to verify that the buyer's 
credit card is still valid. If the card is not valid, the status of CPO 100 is changed to 
"expired" at step 840. The maintenance process is completed at step 850 once all 
"active" CPO database records have been examined. 

Figure 9 illustrates the process by which a potential seller selects CPO 
100. At step 900. the potential seller logs on to central controller 200 using modem 350 
of seller interface 300. At step 910, the potential seller selects an appropriate subject 
area. For example, a large Chicago hotel that had just experienced the cancellation of a 
block of rooms for a convention might search in the hotel subject area in the hopes of 
finding a CPO 100 requesting a room in Chicago on those dates. At step 920. the 
potential seller browses the list of available CPOs 100 (i.e. those with a status of 
"active"). CPOs 100 may be listed with minimal details, with additional infonnation 
available only if the potential seller is interested in binding CPO 100. A hotel CPO 100 
might be listed as "hotel-09/16/96<:hicago-single occupancy-$85." A potential seller 
wanting more information about CPO 100 may request additional data at step 940. In 
one embodiment, each CPO 100 is hyperlinked to a separate web page that provides 
complete details. The potential seller clicks on CPO 100 and is immediately transferred 
to the page of supporting detail. This detail might include the required type of bed, 
fitness faciUties. and restaurants. In another embodiment, CPO 100 is electronically 
transmitted directly to the seller, via electronic mail, fax, telephone, beeper, etc. 

Figures 10 and 1 1 illustrate the process by which CPO 100 is bound by a 
seller. At step 1000, the potential seller selects CPO 100 that he would like to bind, 
developing seller response 110 that represents his intention to bind. At step 1010. 
central controller 200 receives seller response 110 from the potential seller. Central 
controller 200 then timestamps seller response 1 10 and authenticates the identity of the 
seller, as well as verifying his probable capacity to deliver the goods. The timestamp 
allows central controller 200 to determine the fim unconditional acceptance to be 
received. If two seller responses 1 10 are received within a few seconds of each other, 
the timestamp allows central controller 200 to decide which was received first! 
Alternatively, the timestamp may be appended to seller response 1 10 at the time it is 
transmitted from seller interface 300. using clock 335 of seller interface 300. 
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Authentication of the seller's identity involves central controller 200 
extracting the seller ID from seller response 1 10 and looking up the seller's identity in 
seller database 260. Information in seller database 260 then provides an indication of the 
seller's ability to deliver the goods. Before a seller can bind CPO 100 for an airline 
5 Ucket, for example, central controller 200 must audienticate that the seller is an airline. 
If necessary, central controller 200 may verify that the seller can provide the specific 
good requested. Rather than just verifying that the seller is an airline, central controller 
200 may verify that it serves the city pairs requested by the buyer. In another 
embodiment, the seller incorporates seller response 1 10 into CPO 100, signing CPO 100 

10 by adding an indication that the contract is agreed to. This indication could be a digital 
signature, or could involve adding a symbol or indicia representative of the seller. 

Central controller 200 then verifies the status of CPO 100 at step 1030. 
determining whether or not the status of CPO 100 is "active" at step 1040. If CPO ! 00 is 
currently "active." a unique tracking number is added to seller response 110 at step 

15 1060. Central controller 200 then stores seller response 1 10 in seller response database 
270 at step 1070. If the status of CPO 100 is not "active" at step 1040, seller response 
1 10 is refused by central controller 200 and transmitted back to the potential seller at 
step 1050. 

In another embodiment, the seller transmits seller response 1 10 directly 
20 to the buyer at step 1010. The buyer may then send .seller response 1 10 to central 
controller 200 for verification and authentication, or he may choose to accept seller 
response 1 10 without verification and autiientication. 

In Figure 1 1, Uie payment process is begun at step 1 100 when the credit 
card number and approval code for the selected CPO 100 is transmitted to the seller. At 
25 step 1 1 10 CPO 100 is bound, turning CPO 100 into a legally binding contract between 
the buyer and seller. The binding process requires tiiat the status of CPO 100 be 
changed to "completed," preventing subsequent sellers from being able to bind CPO 
100. The binding process also requires that the seller ID be added to CPO 100. At step 
1120. central controller 200 sends purchase confirmation 120 to the seller and then 
30 sends it to the buyer at step 1 1 30. 

In anotiier embodiment, multiple sellers may bind CPO 100. In this case, 
CPO 100 may maintain its status of "active" until a given number of sellers have 
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responded, and only then is the status of CPO 100 changed to "completed." For 
example, a rare coin dealer may post CPO 100 offering a hundred dollars for a specific 
type of coin. A condition of CPO 100 may state that die offer is open to the first ten 
sellers to respond, allowing for ten bindable contracts. Another option is to open CPO 
100 to any number of bindings, or any number of bindings up to the fimds available by 
the buyer. 

There are many methods by which the providers of the system could 
derive a revenue stream. In one embodiment, a flat fee is charged for every CPO 100 
submitted. There could also be flat fees that would cover any number of CPOs 1 00 over 
a given period of time, allowing buyers to subscribe to the service much as they would 
subscribe to a newspaper. In another embodiment, central controller 200 calculates a 
discounted value of the price in which sellers receive only a percentage of the price of 
CPO 100. In another embodiment, advertisers pay to have messages listed along with 
CPOs 100, supplementing the costs of operating the system. Alternatively, the method 
1 5 and apparatus of the present invention may be employed without a payment feature. 

Figure 12 illustrates the exchange of goods between buyer and seller. At 
step 1200, the seller transfers the specified goods to the buyer. This transfer could 
involve the delivery of physical goods as well as digital goods. Physical goods might 
include cars, jewelry, computer equipment, etc. Digital goods might include 
documents, tickets, access codes, etc. A hotel, for example, might transfer a 
confirmation number to the buyer, to be presented upon check-in at the hotel. At step 
1210, the buyer examines the delivered goods to see if they meet all conditions and 
terms of CPO 100. A buyer purchasing a hotel room, for example, would verify that the 
room was for the correct date and was in the correct city. At step 1220, if the goods do 
not meet the buyer's conditions as described-in CPO 100 the buyer contacts an arbiter at 
central conox>ller 200 for dispute resolution. This process is described in more detail in 
the dispute resolution embodiment described later. At step 1240 the transaction is 
complete. 

PAYMENT PREFERENCES 
30 Figure 1 3 illustrates a protocol in which central controller 200 establishes 

buyer account 297. At step 1300, the buyer selects his preferred method of paymem. 
Preferred metiiods might include credit cards, personal checks, electronic funds transfer. 
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digital money, etc. At step BIO, the buyer transmits payment data con^sponding to his 
preferred method of payment to central controller 200. As indicated by box 1315. such 
payment data might include credit card number or bank account number. These 
payment methods are meant to be merely illustrative, however, as there are many 
equivalent payment methods commonly known in the art that may also be used If the 
buyer wants to pay by credit card, for example, payment data would include his credit 
card account number, expiration date, name of issuing institution, and credit limit. For 
electronic funds transfer, payment data includes the name of the buyer's bank and his 
account number. At step 1320. central cont„,ller 200 stores payment data and payment 
preferences in payment database 285. 

At step 1330, central controller 200 establishes buyer account 297 that 
either stores money transferred by the buyer or serves as a pointer to an account of the 
buyer outside the system For buyers using credit cards, for example, buyer account 
297 contains the credit card number, expiration date, and name of issuing institution 
Buyers could also transfer money to centnU controller 200 to be stored in buyer account 
297. which would operate like a conventional checking account. Centml controller 200 
would send a check to the seller written on buyer account 297. Alternatively, central 
controller 200 could electronically move the funds directly f.x,m buyer account 297 to 
seller account 298. At step 1340, central controller 200 contacts the bank or card issuer 
to confinn that funds are available. A buyer is thus unable to use a credit card with no 
credit available to establish buyer account 297. 

The above protocols may be similarly applied to sellers, allowing for the 
creation of seller account 298. The primary difference being that seller account 298 is 
primarily used for deposits, with money flowing from seller to buyer in die case of 
deposit returns or reftmds when the buyer does not find the received goods acceptable 
Venfication of ftmds available is therefore not as important for sellen;. 

Although the on-line embodiment describes a protocol in which central 
controller 200 transmits credit card information to the seller for processing, there are of 
course many payment protocols under which payment may be transferred from buyer to 
seller. In one embodiment, processing the credit card is performed by central contraller 
200. not the seller. Central controller 200 looks up the credit card number of the buyer 
in payment database 285. This credit card number is transmitted to payment processor 
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230. Payment processor 230 contacts the credit card clearinghouse to get an 
authorization number. The billable amount appears on the credit card statement of the 
buyer in his monthly statement. The clearinghouse posts this amount to seller account 
298. Central controller 200 updates payment database 285 to indicate that payment has 
been made. Central controller 200 could also arrange for payment to be made directly 
between buyer and seller by providing payment information to each party. The buyer, 
for example, might receive the checking account number of the seller. Account 
information could also be embedded into CPO 100 and seller response 110, allowing 
buyer and seller to complete payment once they each had a copy of CPO 100. 

Another method of payment involves procedures using digital cash. 
Central controller 200 looks up the buyer's electronic delivery address in payment 
database 285. This address is transmitted to payment processor 230. with the digital 
cash being downloaded from the buyer. Central controller 200 updates payment 
database 285 to indicate that payment has been made. This address might be an 
electronic mail address if the digital cash is to be transferred by electronic mail, or it 
could be an Internet Protocol address capable of accepting an on-line transfer of digital 
cash. This electronic delivery address is sent to payment processor 230. The digital 
cash is downloaded to seller account 298 or directly to the seller. Central controller 200 
then updates payment database 285 to indicate that payment has been made. Using 
these digital cash protocols, it is possible for the buyer to include payment along with 
CPO 100 in electronic form. 

The practice of using digital cash protocols to effect payment is well 
known in the art and need not be described here in detail. For reference, one of ordinary 
skill in the art may refer to Daniel C. Lynch and Leslie Lundquist. Digital Money, John 
Wiley & Sons. 1996; or Seth Godin. Presenting Digital Cash. Sams Net Publishing. 
1995. 

DELAYED PAYMENT EMBODIMENT 
Although the on-line embodiment describes a protocol in which sellers 
receive payment immediately upon binding CPO 100. other embodiments may be 
implemented in which payment is delayed until the goods have been received by the 
buyer, or delayed until some predetermined date. Partial payments and installment 
payments are also supported by the system 



31 



wo 98/10361 



PCT/US97/15492 



Escrow account 299 allows payment to be delayed until the seller 
completes delivery of the goods, while at the same time ensuring that the buyer will in 
fact make payment. Central controller 200 establishes escrow account 299 as a 
temporary holding account. When the seller binds CPO 100 at step 1 1 10. funds ate 
transfened from buyer account 297 to escrow account 299. Only after the goods have 
been received by the buyer are fimds transferred from escrow account 299 to seller 
account 298. The buyer may transmit a digitally signed release message to central 
controller 200, authorizing the release of the escrowed funds to the seller. 

In another embodiment, the buyer makes a partial payment when CPO 
too is bound, and then completes payment when the goods are received. The fraction 
of the offered price of CPO 100 to be paid upon binding is a condition of CPO 100 and 
is stored in payment database 285 when CPO 100 is bound. Central controller releases 
this portion of the fimds at step 1 1 10. and then releases the remaining portion after 
goods have been delivered at step 1200. The partial payment made upon binding may 
be non-refiindable. This would allow a hotel, for example, to sell hotel room 
reservations that are cancelable on two days notice, with cancellations within the two- 
day period resulting in forfeiture of deposit. 

In yet another embodiment. CPO 100 describes the use of installment 
payments. The first payment is made when CPO 100 is bound, followed by regular 
payments as specified in the conditions of CPO 100. The dates at which payments are 
to be made are stored in payment database 285. 

COUNTEROFFER EMBODIMENT 
In one embodiment of the present invention, sellers respond to CPO 100 
not by binding it. but by making a counteroffer with modified and/or additional 
conditions. An airiine, for example, might view CPO 100 for a first class ticket for five 
hundred dollars. The airiine may be willing to sell for six hundred dollars, and thus 
want to develop and issue a counteroffer rather than electing to bind CPO 100. This 
counteroffer is similar to CPO 100 except that the buyer is binding the .seller instead of 
the seller binding die buyer. The counteroffer is also directed to a specific party (the 
buyer), unlike CPO 100 that may be directed to a plurality of sellers. 

Figure 18 illustrates die development of counteroffer 140. At step 1800. 
the potential seller selects CPO 100 for which he wants to make a counteroffer. At step 
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1810. the seller prepares counteroffer 140 with modified conditions. Hie seller follows 
the same process that the buyer uses to generate CPO 100 (steps 500 through 580). 
selecting the conditions of counteroffer 140. Alternatively, the seller is presented with 
an electronic copy of CPO 100 and is allowed to edit those conditions that the seller 
wants to change. For example, a car rental company might take the buyer's request for a 
ten dollar per day luxury car and counteroffer with a twenty-dollar per day compact car. 
At step 1820, die seller attaches the tracking number of CPO 100 to counteroffer 140. 
Central controller 200 receives counteroffer 140 at step 1830. setting the status to 
"active." Central controller 200 then adds a unique tracking number to counteroffer 140 
at step 1840. and stores it in counteroffer database 267 at step 1850. Central controller 
200 extracts the tracking number of CPO 100 attached to counteroffer 140 in order to 
find the buyer to whom counteroffer 140 is transmitted at step I860. 

Figure 19 illustrates the process by which the buyer re.sponds to 
counteroffer 140. At step 1900. the buyer decides whether or not to bind counteroffer 
140. If he does not bind, counteroffer 140 is transmitted back to the potential seller at 
step 1910. If the buyer does decide to bind, buyer response 150 is transmitted to central 
controller 200 at step 1920. At step 1930, funds are removed from buyer account 297 
and placed in seller account 298. At step 1940. the status of counteroffer 140 is 
changed to "completed." Purchase confirmation 120 is transmitted to the seller at step 
1950 and transmitted to the buyer at step 1960. Pixjcedures for the exchange of goods 
are completed as described in Figure 12. 

OFF-LINE EMBODIMENT 

In one embodiment of the present invention, buyers and sellers 
communicate in an off-line manner with central controller 200. Rather than sending 
electronic mail or using web-based servers, buyeni and sellers use a telephone, fax 
machine, postal mail, or other off-line communication tool. 

A buyer may use a telephone, for example, to generate CPO 100. The 
buyer calls central controller 200 and is connected with an agent. The buyer provides 
the terms of CPO 100 such as subject, description of goods. condiUons, expiration date, 
price, etc. The buyer also provides his buyer ID. password, or private key so that 
central controller 200 can authenticate his identity. The agent puts this data into digital 
form by typing it into a terminal and then adds legal language to form CPO 100. CPO 
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100 is then transmitted to central controller 200 where it is made available to potential 

sellers as described in the on-line embodiment 

In an alternative embodiment, the buyer calls central controller 200 and 
is connected with a conventional Interactive Voice Response Unit (IVRU) which allows 
the buyer to enter some or all of the terms of CPO 100 without the assistance of a live 
agent. The buyer initially selects from a menu of subjects using the touch-tone keys of 
his phone, and then the call is either directed to a live agent specializing in that subject 
area, or the buyer is prompted for further terms of CPO 100. 

Potential sellers may also use a telephone to browse and bind CPOs 100. 
The potential seller calls central controller 200 and selects a subject. Central controller 
200 then converts ti,e text of each CPO 100 into audio form, reading the entire list to the 
potential seller. At any time during the reading of CPOs 100, the potential seller may 
press a combination of keys on his telephone to select CPO 100 for binding. The seller 
enters seller ID number and is authenticated by central controller 200 prior to the 
binding of CPO 100. Potential sellers could also enter parameters before having the list 
of CPOs 100 read to them. An airline, for example, might request that all airline CPOs 
100 for more than eight hundred dollars be read, skipping any CPO 100 with a lower 
price. 

Buyers may also communicate with an agent at central controller 200 
through faxes or postal mail. The agent receives the message and proceeds to digitize it 
and form CPO 100 as described above. 

CRYPTOGRAPHIC AUTHENTICATION EMBODIMENT 
In the previous embodiments, authentication of the buyer and seller 
involves checking the attached ID or name and comparing it with those stored in seller 
database 260 and buyer database 255. Although this procedure works well in a low 
security environment, it can be significantly improved through the use of cryptographic 
protocols. These protocols not only enhance the ability to authenticate the sender of a 
message, but also serve to verify the integrity of the message itself, proving that it has 
not been altered during transmission. A small airiine, for example, could be prevented 
from binding CPOs 100 requiring performance by a large carrier as their identity would 
not be authenticated. Encryption can also prevent eavesdroppers from learning the 
contents of the message. A competing airline, for example, could be prevented from 
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reading any intercepted seller response 110 generated by another competitor. Such 
techniques shall be referred to generally as cryptographic assurance methods, and will 
include the use of both symmetric and asymmetric keys as well as digital signatures and 
hash algorithms. 

The practice of using cryptographic protocols to ensure the authenticity 
of sender, as well as the integrity of messages is well known in the art and need not be 
described here in detail. For reference, one of ordinary skill in the art may refer to 
Bruce Schneier, Applied Cryptography. Protocols. Algorithms. And Souree Code In C. 
(2d Ed. John Wiley & Sons. Inc.. 1 996). 

Figure 14 describes a symmetric key embodiment in which the seller and 
central contn,ller 200 share a key. Thus both encryption and decryption of seller 
response 1 10 are performed with the same key. This encryption may be implemented 
with an algorithm such as DES (U.S. Government standard, specified in FIPS PUB 46). 
or with any of several algorithms known in the art such as IDEA. Blowfish. RC4. RC2. 
SAFER, etc. The seller encrypts seller response 1 10 with his assigned symmetric key at 
step 1400. using cryptographic pnxessor 310 of seller interface 300. The key may be 
•stored in message database 370 or odierwise stored or memorized by tiie seller. The 
encrypted seller response 110 is then transmitted to cryptographic processor 210 of 
central controller 200 at step 1410. Cryptographic processor 210 extracts the seller ID 
from seller response 1 10 at step 1420 and looks up the symmetric key of the seller in 
cryptographic key database 290 at step 1430, decrypting seller response 1 10 with this 
key at step 1440. Cryptographic key database 290 contains algorithms and keys for 
encrypting, decrypting and/or authenticating messages. At step 1450, if the resulting 
message is intelligible, then it must have been encrypted by the same key, 

authenticating that the seller must have indeed been the autiior of seller response 1 10. 

This procedure makes it significantly more difficult for an unautiiorized 
seller to represent himself as a legitimate seller. Without cryptographic procedures, an 
unauthorized seller who obtained a sample seller response 1 10 from a legitimate seller 
would be able to extract the seller ID and then attach this ID number to unautiiorized 
seller responses 1 10. When seller response 1 10 has been encrypted with a symmetric 
key. however, an unautiiorized seller obtaining a sample seller respome 1 10 only 
discovers Uie seller's ID number, not tiie symmetric key. Without this key. the 
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unauthorized seller cannot cn^ a seller response 1 10 that will not be discovered by 
central controller 200, since he cannot encrypt his message in the same way that the 
authorized seller could. The symmetric key protocol also ensuies that seller response 
1 10 has not been tampered with during transmission, since alteration of the message 
requires knowledge of the symmetric key. An encrypted seller response 110 also 
provides the seller with more anonymity. 

Referring now to Figure 15. there is shown an asymmetric key protocol 
in which seller response 1 10 is encrypted with a private key and decrypted with a public 
key. Two such algorithms for this procedure are RSA and DSA. At step 1500 the 
seller encrypts seller response 1 10 with his private key using cryptographic processor 
310. transmitUng seller response 110 to central controller 200 at step 1510 
Cryptographic processor 210 extracts the seller ID at step 1520 and looks up the seller's 
associated public key in cryptographic key database 290 at step 1530, decrypting seller 
response 1 10 with this public key at step 1540. As before, if seller response 1 10 is 
intelligible then central controller 200 has authenticated the seller at step 1550. Again 
unauthorized sellers obtaining seller response 110 before it was received by central 
controller 200 are not able to undetectably alter it since they do not know the private 
key of the seller. Unauthorized sellers would, however, be able to read the message if 
they managed to obtain the public key of the seller. Message secrecy is obtained if the 
seller encrypts seller response 1 10 with his public key. requiring the attacker to know 
the seller's private key to view seller response 110. 

Figure 16 shows a cryptographic technique using digital signatures to 
provide authentication and message integrity. One such algorithm is DSA (Digital 
Signature Algorithm), the U.S. Government standaid specified in FIPS PUB 186. As in 
the asymmetric protocol described above, each seller has an associated public and 
private key. The seller signs seller response 1 10 with his private key at step 1600 with 
cryptographic processor 310 and transmits it to central controller 200 at step 1610. 
Central controller cryptographic processor 210 extracts the seller ID at step 1620 and 
looks up the seller^ public key at step 1630. verifying the signature using seller 
response 1 10 and the public key of the seller at step 1640. If seller response 1 10 is 
intelligible, then central controller 200 accepts seller response 1 10 as authentic at step 
1650. 
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Referring now to Figure 17, there is described a cryptographic technique 
using message authentication codes for verifying the authenticity and integrity of seller 
response 110. In the hash protocol of the present invention, the seller and central 
controller 200 share a symmetric key, which the seller includes in a hash of seller 
5 response 1 10 at step 1700. In the hash protocol, a one-way function is applied to the 
digital representation of seller response 1 10, generating a code that acts much like the 
fingerprint of seller response 1 10. Any of the MAC algorithms, such as RIPE-MAC, 
IBC-Hash, CBC-MAC, and the like may be applied in this application. After 
transmitting seller response 110 to central controller 200 at step 1710, cryptographic 

10 processor 210 extracts seller ID from seller response 110 at step 1720. Then 
cryptographic processor 210 looks up the seller's symmetric key at step 1730 and hashes 
seller response 1 10 with this symmetric key at step 1740, comparing the resulting hash 
value with the hash value attached to seller response 110. If the values match at step 
1750, the integrity of seller response 1 10 is verified along with the authenticity of the 

15 seller. 

Although cryptographic techniques can provide greater confidence in the 
authenticity of seller response 1 10, they are useless if the seller's cryptographic keys are 
compromised. An attacker obtaining the symmetric key of another seller is 
indistinguishable from that seller in the eyes of central controller 200. There is no way 

20 to know whether the seller was the true author of seller response 110, or an attacker 
with the right cryptographic keys. One way to solve this problem (known as undetected 
substitution) is to use biometric devices such as a fingerprint reader, voice recognition 
system, retinal scanner and the like. These devices incorporate a physical attribute of 
the seller into seller response 1 10, which is then compared with the value stored in seller 

25 database 260 at central controller 200. In the present invention, such devices attach to 
seller interface 300. 

Fingerprint verification, for example, may be executed before the 
creation of seller response 1 10, during the generation of seller response 1 10 in response 
to prompts from central controller 200, at some predetermined or random times, or 
30 continuously by incorporating the scanning lens into seller interface 300 such that the 
seller is required to maintain his finger on the scanning lens at all times for continuous 
verification while seller response 1 10 is generated. 
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An example of such an identification device is die FClOO 
FINGERPRINT VERIFIER available from Startek. a Taiwanese company. The FCIOO 
is readily adaptable to any PC via an interface card. The fingerprint verifier utilizes an 
optical scanning len.. The seller places his finger on the lens, and the resulUng image is 
5 scanned, digiUzed. and the data compressed and stored in memory. Typically a 256- 
byte file is all that is required. Each live-scan fingerprint is compared against the 
previously enrolled/stored template, stored in data storage device 360. If the prints do 
not match, the cryptographic algorithms executed by cryptographic processor 335 may 
prevent the seller from generating a seller response 1 10. 
>0 in a voice verification embodiment, the seller's voice is u.sed to verify his 

identity. This embodiment has the advantage of not requiring the use of any specialized 
hardware since it can be implemented over a standard phone connection. The seller's 
identity is verified at central computer 200. The process of obtaining a voice-print and 
subsequently using it to verify a person's identity is well-known in the art, and therefore 
15 need not be described in detail herein. One of ordinary skill in the art may refer to 
SpeakEZ. Inc. for voice identificaUon/verification technology. Conventional speaker 
Identification software samples the seller^ voice. This sample is stored at central 
controller 200 in seller database 260. Each time the seller wants to transmit seller 
response 1 10 to central controller 200, he is required to call central controller 200 and 
20 .speak into the phone at die prompt for a voice sample. If this sample matches that 
stored in seller database 260. die seller is provided a password which is incorporated 
mto die digital signature appended to seller response 1 10. Any seller response 1 10 
received widiout an appropriate voice match password is not accepted. The voiceprint 
may also be stored in a database wiUiin data storage device 360 of seller interface 300 

25 to verify theseller'sidentitylocallypriortoallowingsellerre.«!ponse llOtobecreated. 

Although die above cryptographic and biometric protocols describe die 
authentication and validadon of seller response 1 10. diey may be equally applied to die 
audientication and validation of CPO 100. counteroffer 140, buyer response 150 
purchase confirmation 120, or any odier message or communication between buyers, 

30 sellers, and central controller 200. 
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ANONYMOUS TRANSACTIONS EMBODIMENT 
As mentioned previously, the present invention provides for the 
anonymity of both buyers and sellers. Such anonymity is accomplished by eliminating 
all references to the names of the individuals for all transactions. A buyer, for example, 
would include his ID in CPO 100 rather than his name, preventing the seller receiving 
CPO 100 from discovering the buyer's identity. This is desirable if the buyer were a 
biotech firm that did not want rivals to know the type of lab equipment that the 
company was looking for. 

In a similar manner, sellers may also want to keep their identity a secret. 
An airline might not want the public to know that they are heavily discounting fares 
between certain cities. 

Although using ID numbers can provide anonymity, both for buyers and 
sellers, there are a number of potential weaknesses. First, if the database of ID 
numbers, stored in buyer database 255 or seller database 260. and their respective 
buyers/sellers is compromised, anonymity is destroyed since the message sender can be 
looked up in buyer database 255 or seller database 260. To prevent this, the ID numbers 
are encrypted with the public key of central controller 200. so tiiat even if it is stolen it 
is useless without the private key. 

Although we have described only one possible method for maintaining 
anonymity, there are other equivalents. For example, if the embodiment included 
telephone messaging, the identity of the buyer and seller could be maintained using 
conventional voice modification techniques. If CPO 100 or seller response 1 10 were in 
a paper form, the form could be scanned using optical character recognition and 
translated into digital form, discarding any information that could be found in the 
original document. 

TRUSTED SERVER EMBODIMENT 
In one embodiment of the present invention, central controller 200 is 
separated into three distinct elements: operations server 160. trusted server 165, and 
bonding agency 170. Each server performs a disUnct task in the process of managing 
CPO 100. This separation tnakes it more difficult for attackers to compromise the 
system, as they must defeat the security of three separate systems instead of one. As 
indicated in Figure 20. these servers woric in conjunction with buyer interface 400 and 
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seller interface 300. Operations server 160 has the task of posting CPOs 100. and 
accepts all transactions previously authenticated by trusted server 165. Tnisted server 
165 authenticates the identity of buyers and sellers, while bonding agency 170 verifies 
the ability of buyers to pay and the ability of sellers to deliver on bound CPOs 100. In 
this embodiment, each server type may be distributed over a number of servers. 

The following protocols describe the interactions of the three servers and 
assume the following: 

1 . Everyone knows the public keys of operations server 160, trusted 
server 165. and bonding agency 170. 

2. The buyer and potential seller have bond certificates 172, as 
discussed below. 

3. Public keys can be used both for encryption and for signing. 
Before CPO 100 is accepted by operations server 160. it must bear the 

digital signature of both tnisted server 165 and bonding agency 170. Because of this, 
CPO 100 contains two additional elements - a trusted server ID and a bond certificate. 

The trusted server ID is the ID number of the tnisted server 165 that 
authenticated the buyer who created CPO 100. The "bond certificate" is a public key 
certificate, with the certifier (bonding agency 170) specifying a .set of valid dates for 
bond certificate 172. a limit to the amount covered, and a set of additional conditions. 
These additional conditions may require on-line checking of a revocation li.st. may 
specify operations server 160 and tnisted server 165 to be used. etc. The private key 
coni!sponding to the public key certified is not known to bonding agency 170 - only to 
the user. Knowledge of that private key is used as proof of identity for the bondholder. 
(This allows buyer and seller anonymity in many cases, though of courc. neither will 
be anonymous to bonding agency 170 except in very special cases.) 

Bond certificate 172 for the buyer will be referred to as BCB, while the 
conesponding public and private keys will be referred to as PKB and SKB. 
respectively. 

CPO 100 is posted by an interaction between the buyer, tnisted server 
165. and operations server 160. This part of the protocol is possible with nothing more 
than encrypted e-mail transmitted among the parties. 
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Before CPO 100 may be posted, the buyer must get approval from 
trusted server 165. This is required so that both the buyer and operations server 160 
know that trasted server 165 theyVe designated to decide whether or not the contract 
has been fulfilled is actually willing to accept CPO 100. OperaUons server 160 will not 
5 accept CPO 1 00 without a TRUSTED_ACCEPTANCE message as described below. 

The trusted server 165. in turn, will not issue a 
TRUSTED_ACCEPTANCE unless it is convinced that the buyer's CPO 100 is fresh 
(not a replay), and that the buyer's ability to pay is guaranteed by bonding agency 170. 
The buyer must also be convinced that he is being issued a fresh 
10 TRUSTED_ACCEPTANCE. 

The protocol works as follows: 
1. The buyer forms 

UO = -REQUEST FOR TRUSTED APPROVAL" 
XO = UO. CPO, RO, Additional Terms 
'5 and sends to trusted server 165 

MO = PKEPKA (XO, Sign SKB (XO)). 



2. Trusted server 165 responds with 

Ul = "TRUSTED CPO CHALLENGE" 
20 R I = a 1 60-bit random number 

XI =U1 hash(XO),RI 
and sends to the buyer 

Ml = PKEPKB (XI, SignSKA (XI)). 

25 3. The buyer responds to this with 

U2 = "BUYER CPO RESPONSE" 

X2 = U2. hash (XI) 
and sends to trusted server 165 

M2 = PKEPKA (X2, SignSKB (X2)). 
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Trusted server 165 responds with 

U3 = "TRUSTED CPO ACCEPTANCE" 
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T3 = Timestamp 
X3 = U3. hash (X2), T3. CPO 
and sends to the buyer 

M3 = PKEPKB (X3. SignSKA (X3)). 
5 5. The buyer stores X3 as TRUSTED_ACCEPTANCE. 

In order for operations server 160 to post CPO 100. it must be convinced 
that CPO 100 has a fresh TOUSHED.ACCEPTANCE, and that it is guaranteed by 
bonding agency 170. This works as follows: 
'° 1- The buyer forms 

R0 = random 160-bit number 
UO = "CPO SERVER SUBMISSION" 
XO = UO, RO. TRUSTED_ACCEPTANCE 
and then sends to operations server 160 

MO = PKEPKS(XO,SignSKB(XO)). 

2. Operations server 160 receives MO and verifies it. If it's fresh 
(not a replay), and if operations server 160 is willing to post CPO 100, it forms 

Rl = a random 160-bit number 
Ul = "SERVER CPO CHALLENGE" 
XI = |.hash(XO).RI 
and then encrypts and sends to the buyer 

Ml = PKEPKB (XI, SignSKS (XI)). 

3. The buyer forms 

U2 = "CPO RESPONSE TO SERVER CHALLENGE- 
RS and then sends to operations server 1 60 

M2 = PKEPKS (X2, SignSKB (X2)). 

4. If this message's signature verifies property, then operations 
server 160 posts the CPO. Operations server 160 forms 

U3 = "POSTED CPO RECEIPT" 
^ CPO = U3,hash(X2).CPO. 

It then sends to the buyer 

M3 = PKEPKB (CPO. SignSKS (CPO)). 
42 
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At the end of this protocol, the buyer has a receipt to acknowledge that 
his CPO 100 has been posted, and operations server 160 is convinced that the holder of 
bond certificate 172 has just agreed to CPO 100, and has the approval of trusted server 
165. 

The potential seller has a bonding certificate 172 (BCP) of his own. 
Before he is allowed to browse CPOs 100 in real time (with the ability to bind them), he 
must go through a protocol. (CPOs 100 may be available to people who aren\ 
browsing, but nobody is allowed to bind CPOs 100 until they go through this protocol.) 
The purpose of this protocol is to prove that the seller is guaranteed by bonding agency 
170 to be capable of delivering the required goods, and also to decrease the 
computational load on operations server 160 by establishing a secret authentication key, 
Kp. All of this decreases the computational expense of allowing the potential seller to 
browse CPOs 100. 

1 . The potential seller forms 

RO = a random 160-bit number 
T = a time range 

UO = "REQUEST FOR ACCESS TO BROWSE" 
XO = UO. RO, T, BCP 
and sends to operations server 160 

MO = PKEPKS (XO, SignSKP (XO)). 
2- Operations server 160 decides whether to grant the potential 
seller access. If so, it forms 

Rl = a random 160-bit number 

Ul = •'SERVER BROWSE-ACCESS CHALLENGE" 

XI =Ul,hash (X0),R1 
and sends to the potential seller. 

Ml = PKEPKP (XU SignSKS (XI)). 
3. The potential seller responds by forming 

U2 = "BROWSE-ACCESS RESPONSE" 
and sends to operations server 1 60 

M2 = PKEPKS (X2, SignSKP (X2)). 
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Operations server 160 verifies the signature, and then responds by 
U3 = "BINDING KEY" 

Kp = a random secret key to be used for binding CPOs 
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T = a time range (from first protocol message) 
X3 = U3, hash (X2), T, Kp 
and sends to the potential seller 

M3 = PKEPKP (X3, SignSKS (X3)). 
'0 At the end of this protocol, the potential seller holds the secret shared key 

with which he is allowed to bind CPO 100. within the time limits specified in the last 
message. The potential seller and operations server 160 an. both convinced that they 
have interacted with one another in real-time, and operations server 160 know.s that the 
potential seller's capacity to deliver on bound CPOs 100 are guaranteed by bonding 
15 agency 170. 

As the potential seller browses CPOs ICQ. each is sent to him by 
operations server 160. authenticated under Kp. and including a random challenge to 
prevem replay attacks. When the potential seller wants to bind one. he forms an offer to 
bmd CPO 100, and sends it, along with the hash of the authenticated CPO 100 
10 authenticated under Kp. Operations server 160 is convinced that this is a valid offer to 
bind CPO 100. and that it's happening in real time. I, .^sponds by sending him 
BOUND_CPO. 

I . Operations server 1 60 forms 
U0= "CPO OFFER" 
RO = a random. 1 60-bit number. 
XO = UO, RO. CPO description 
and sends the potential seller 

MO = PKEPKP (XO, AuthKp(XO)). 
(Note that this step is repeated for each CPO 100 browsed.) 
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2. The potential seller forms 

Ul = "CPO OFFER TO BIND" 
Rl = a random 160-bit number 
XI = Ul. hash (XO), Rl. Offer Details 
and encrypts and sends to operations server 160 
Ml = PKEPKS (XI. AuthKp(Xl)). 

3. If the offer is acceptable to operations server 160, then it forms 

U2 = "SERVER BINDING OF CPO" 
T = timestamp 

X2 = U2, hash (XI). BCP. T. CPO. Offer Details and 
encrypts and sends to the potential seller 

M2 = PKEPKP (X2, SignSKS (X2)). 



4. The potential seller stores X2. SignSKS (X2) as BOUND_CPO. 

The "Offer Details" field of BOUND.CPO specifics the conditions of 
CPO 100. In most cases, this will involve delivering some goods in exchange for 
payment, possibly in the presence of an agent from trusted server 165. In some cases, 
however, this will involve intermediaries, to preserve anonymity for the potential buyer, 
the seller, or both, it is important that the potential seller has the BOUND_CPO so that 
he can prove his identity to the buyer or an intermediary with a simple challenge- 
response protocol. 

This set of protocols describes one possible implementation of an 
infrastructure to support CPOs 100. It is important to note that operations server 160. 
trusted server 165, and bonding agency 170 can conceivably be the same entity. In this 
case, these protocols can be dramatically simplified. 

BARTER EMBODIMENT 

Not all transactions require the transfer of money from buyer to seller. In 
a barter transaction the distinction between buyer and seller disappears, resulting in a 
contract between a first party and a second party. The first party posts CPO 100. and 
the second party binds it. Instead of getting cash, the second party receives goods from 
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the first party. A first party who wanted to get rid of a motorcycle, for example, could 
post CPO 100 in which he offered to exchange the motorcycle for a first class ticket 
from New York to London. 

ARBITRATION PROTOCOLS 

Although the previous embodiments have described the delivery of 
goods from seller to buyer as the end of the process, there will inevitably be disputes 
arising from some transactions, requiring follow-up activity to resolve these disputes. 
The present invention can support dispute resolution in two ways. 

First, language can be built into every CPO 100 requiring that both 
parties submit to binding arbitration of all disputes, helping to avoid more costly and 
time consuming legal battles in a court of law. Additionally, liquidated damages may 
be set which specify damage amounts for particular infractions of CPO 100. 

Second, central controller 200 can support the arbitration process by 
providing an arbiter for each dispute. Such arbitration might be required when goods 
shipped from die seller do not correspond to the conditions of CPO 100. A buyer 
seeking a non-stop airline ticket, for example, might seek damages against a seller who 
delivered a ticket with one or more stops. Similarly, a business traveler whose CPO 100 
for a non-smoking hotel room might seek damages from the hotel which bound the CPO 
with a smoking room. Instead of seeking damages, the buyer may seek replacement of 
the goods, such as another airiine ticket that was non-stop. In an arbitration involving 
airiine tickets, the buyer may submit a copy of the ticket to central controller 200 along 
with the tracking number of CPO 100. allowing the arbiter to establish whether or not 
the seller fulfilled the conditions of CPO 100. Sellers may also initiate arbitration 
proceedings if they havfe shipped the goods and have not yet received payment from the 
buyer. 

In an alternative embodiment, transaction data can be sent to third party 
arbiters outside the system. Central controller 200 may send a copy of CPO 100. seller 
response 110, and purchase confirmaUon 120 to the arbiters. Cryptographic keys may 
also be provided to the aibiters if there are questions of authenticity or non-repudiation. 
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APPUCATIONS OF THE INVENTION 
In order to clarify the application of the present invention, the following 
examples demonstrate potential needs of end users: 
CPO: Airline tickets 
5 Four tickets needed 

From Chicago, OHare or Midway to Phoenix. 
Leaving on April 12 or 13 
Returning on April 18 or 19. 
Any of the six largest carriers acceptable. 
0 Change of planes is acceptable if layover is less than 2 hours. 

ni bind at $ 1 80 per ticket, excluding tax. 
CPO: Hotel accommodations 
Five nights lodging 

Arrive April 12 or 13, Depart April 18 or 19 
5 Within 30 minutes drive time of downtown Phoenix. 

Double bed 
Non-smoking 

Hotels, motels or bed & breakfasts are acceptable 
Must be AAA q^proved or Mobil 2* or better. 
^> ni bind at $55 per night (excluding tax). 

CPO: New car purchase 
1997 Ford Taums 
Must be in dealer stock 
GL package w/air conditioning 

> AM/FM/Cassette (Stock #1 224-099) 

May have other options already installed 
Can be white, tan, green or maroon 
Must have 100 miles or less, never titled. 
No dealer demo cars 

> Delivered to me no later dian July 15, 1996 

Loan pre-approval: Chase Manhattan #1220-998-887AD-2I 
III bind at $21,350 
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CPO: Car insurance 

1997FoitlTauras 

1 driver, age 40, male 

Reside in Ridgefield, CT 

Drive to work 30 miles 

Collision included 

$500 deductible 

Glass coverage included 

No speeding infractions in last 3 years 

No accident in past 3 years 

IMM liability umbrella 

Driver's license #CT 1222-221-2298 
Carrier must be rated A or better by AM Best, 
ni bind at $1,200 per year 
CPO: U.S. silver dollars 

1 886 Morgan 

Philadelphia mint mark 

Sealed in ANA packaging 

MS94 or better grade 

I will purchase up to 6 total 

Sellers may fulfill all or part of order 

ni bind at $225 each 

Offer Administrator Coinworid. P.O. Box 10(K), N.Y., N. Y. 
Mr, K, Smith 212-222-1000 
CPO: Industrial commodity 

My company wants to purchase 40 tons of steel 
Grade 120 

Delivered FOB to NY, NY 
Class 4 Slabs or Class 12 ingots 
Alloy RT^ 12 or equivalent 
Deliver by August 1, 1996 
Maximum price known to Citibank 
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First bid below maximum will bind 
Citibank to provide instant price verification 
1 bid per supplier per day (GMT) 
E-mail @ metals.biddesk4022Citi.com 
Letter of Credit payment. Citibank 100-887-9877 
CPO: Credit Card Application 
VISA Gold Canl 
Credit line $5,000 
Interest rate 1 2% or lower 
ni bind at $10 per year 

Financial history available at http://www.provider/-shapiro23 
CPO: Reward for Return 

Briefcase lost with imponant computer disks inside 
Disks labeled RT-554 IBM 
Case is brown leather, brass snaps, RL monogram 
Left on NYC subway, April 7, 1996 F Train. 
Ill bind at $500 

Provide lost & found receipt # to claim reward 
Offer Administrator: NYC Police Lost & Found 
Mr. K. Smith 212-555-1000 



INDUSTRIAL APPLICABILITY 
In view of the foregoing detailed description, it is evident that the instant 
invention may be used to create one or more of the following systems, among others: 

- a system which allows a seller to meet the terms of the purchase offer 
to bind the buyer to accept the seller's fulfillment of that offer; 

- a system which allows the seller to be able to collect ftinds immediately 
upon his acceptance of the buyer's terms as set forth in the purchase offer. 

- a system that allows for a trusted thiitl-party administrator whose 
decision regarding the fulfillmenu adequacy or interpretation of any aspect of the 
process shall be binding on the parties; 
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- a system which allows the seller to receive part of his payment upon 
agreeing to the buyer's purchase offer, and a subsequent payment upon delivery of the 
goods or services called for in the buyer's purchase offer, 

- a system which allows either buyers or sellers to remain anonymous up 
5 until such time as an agreement is consummated and for buyers to remain anonymous 

even after the agreement is consummated by using the trasted third-party as a relay 
system for delivery of goods or services called for by the buyer's purchase offer; 

- a system which ensures that buyers using the inventive system are not 
inundated with inquiries or acceptances from unqualified sellers; 

'0 ' a system which provides a system in which the identity of the buyer is 

authenticated along with the integrity of the buyer's purchase offer. 

- a system in which the identity of the seller is authenticated in order to 
determine the seller's capacity to satisfy the conditions of the purchase offer; 

- a system which allows sellers to submit authenticatablc counteroffers to 

15 the buyer; 

- a system in which counteroffers may allow the buyer to bind the seller 
to the counteroffer, subject to the authenticatablc terms of that counteroffer; 

- a system which allows for delivery of digitally-based products such as 
certificates of insurance from the seller to the buyer according to the terms of the 

20 buyer's purchase offer and the cryptographic validation of such delivery; 

- a system which allows for purchase offers where more than one seller 
may bind the buyer to the purchase offer; and 

- a system which shows how all or part of the system can be practiced 
using non-electronic means such as printed media or advertisements in newspapers. 

25 In view of the aforementioned detailed description of the present 

invention, it is readily apparent that the present invention provides a method and 
apparatus for prospective buyers of goods or services to communicate a binding 
purchase offer globally to potential sellers, for sellers conveniently to search for 
relevant buyer purchase offers, and for sellers to bind a buyer to a contract based on the 

30 buyer's purchase offer. Additionally, the present invention can effectuate performance 
of the agreement between the buyer and seller by guaranteeing buyer payment for the 
purchase. The present invention is therefore a highly effective bilateral buyer-driven 
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commerce system which improves the ability of buyers to reach sellers capable of 
satisfying the buyer's purchasing needs and improves sellers' ability to identify 
interested buyers. 

In one embodiment of this invention, communications between buyers 
and sellers are conducted using an electronic network and central controller. A buyer 
who wishes to make a purchase accesses the central controller located at a remote 
server. The buyer will then create a conditional purchase offer ("CPO") by specifying 
the subject of the goods he wishes to purchase, a description of the goods he wishes to 
obtain, and any other conditions the buyer requires. For example, a typical CPO could 
specify that the buyer wants to purchase a block of four airline tickets from Chicago's 
O'Hare Airport to Dallas. Texas, the tickets must be from any of the six largest U.S. 
carriers, the buyer is willing to change planes no more than once so long as the 
scheduled layover is less than two hours, and the buyer is willing to pay $180 per ticket, 
plus any applicable taxes. 

The buyer then attaches a user identification to the CPO and transmits 
the CPO to the central controller. Under the present invention, the CPO may be 
transmitted via numerous means including a world-wide-web interface, electronic mail, 
voice mail, facsimile, or postal mail. Standard legal provisions and language are then 
integrated with the CPO to Till in the gaps ' of the buyer's purchase offer. Alternatively, 
the CPO may be developed while the buyer is on-line with the central controller. 

Before communicating the CPO to potential sellers, the central comroller 
authenticates the buyer's identification number against a buyer database. The central 
controller may require that the buyer provide a credit card number and may also ensure 
that the buyer has sufficient credit available to cover the purchase price specified in the 
CPO by contacting the credit card clearinghouse. The central controller then assigns a 
unique tracking number to the CPO and globally displays the CPO in a manner such 
that it is available to be viewed by any interested potential sellers. CPOs may be 
displayed by subject category to make it easier for potential sellers to identify relevant 
CPOs. Thus, a seller could log onto a web-site, for example, and see a listing of CPO 
subject categories. The seller could then choose a particular subject and have the ability 
to browse CPOs which correspond to that subject category. In one embodiment, the 
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seller may be required to provide qualifications in order to view the CPOs of a given 
subject category. 

If, after reviewing a particular CPO, a potential seller wishes to accept 
the CPO the seller communicates his intent to the central controller. The central 
5 controller then timestamps the message from the seller and authenticates the identity of 
the seller and his capacity to deliver the goods sought by the buyer. The system then 
verifies that the particular CPO is still "active" and capable of being accepted. If a CPO 
is capable of being accepted only by one seller, it is "completed" when the first qualified 
seller accepts it. Subsequent sellers will not be able to accept a "completed" CPO. If a 

10 seller accepts an active CPO, a unique tracking number is assigned to the seller's 
acceptance. The acceptance is then stored in a database. The buyer and seller are now 
parties to a legally binding contract. 

In another embodiment, the central controller manages the payment 
system between the buyer and seller automatically. Various methods of payment may 

15 be utilized by the invendon, including credit cards, personal checks, electronic funds 
transfer, debit cards, and digital cash. The payment system may also involve the use of 
an escrow account associated with the buyer wherein funds advanced by the buyer to 
cover the purchase of a desired good can be kept pending acceptance by a qualified 
seller. Moreover, the timing of payment to the seller can be varied. The seller can be 

20 paid immediately after the seller accepts the CPO or payment can be delayed until after 
the seller pCi forms his obligations under the contract. 

In yet another embodiment of the present invention, a seller is given the 
option to respond to a CPO by issuing a binding counteroffer with conditions different 
from the original CPO. The seller transmits the counteroffer to the central controller 

25 that then forwards the counteroffer to the buyer. The buyer is then given the option of 
accepting the counteroffer and thereby binding the seller to a contract. 

The present invention can also be practiced in off-line embodiments. 
Instead of using electronic mail or web-based servers, buyers and sellers may 
communicate with the central controller via telephone, facsimile, postal mail, or another 

30 off-line conununication tool. For example, buyers may use telephones to create CPOs 
(with or without the assistance of live agents) and potential sellers may use a telephone 
to browse and bind CPOs. 
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In another on-line en)bodiment, cryptographic protocols are used to 
authenticate the identity of buyers and/or sellers and verify the integrity of buyer and 
seller communications with the central controller. Using cryptography and biometrics, 
the central controller can make it significantly more difficult for unauthorized persons to 
5 tamper with the system by passing themselves off as legitimate buyers or sellers or 
eavesdropping on system communications. 

Anonymity is another advantage of the present invention. For numerous 
privacy and competitive reasons, buyers and sellers often prefer not to have their 
identities revealed to the general public when engaging in commercial transactions. The 
10 present invention effectuates the anonymity of buyers and sellers through the use of 
identification numbers stored in a database secured by the central controller. 

One embodiment of the present invention divides the functionality of the 
central controller into three components and embodies them in three separate servers: an 
operations server, a tmsted server, and a bonding agency. The trusted server 
15 authenticates the identity of buyers and sellers while the bonding agency verifies their 
ability to pay or deliver goods. The operations server posts the CPO, relying upon 
messages from the other two servers for validation. This configuration allows for 
greater specialization of the servers. 

Another embodiment of the present invention does not require a transfer 
20 of money from a buyer to a seller. Instead, the system may be used to consummate a 
contract involving an exchange of goods, services, or other non-monetary consideration. 

Finally, an embodiment of the present invention includes a mechanism 
for resolving disputes between buyers and sellers arising out of agreements 
consummated using the system. The parties may be required in CPOs to stipulate to 
25 binding arbitration and may be assisted .in the arbitration process by the central 
controller. The central controller may serve as an arbitrator or may refer the dispute to a 
third-party arbitrator for resolution. 

What the present invention accomplishes, which no previous system has 
done before, is literally to hang buyer money out on a clothesline for all sellers to sec. 
30 Attached to the money is a note describing what the seller has to agree to do in order to 
take the money down off the clothesline. There is no uncertainty or waste of time on 



53 



wo 98/10361 



PCT/US97/154W 



the part of the seller. He knows that if he can meet the conditions set forth by the buyer, 
he can immediately close the sale and get paid for it. No hassles. No negotiations. 

The invention also allows buyers to reach a large number of remotely 
located sellers who normally would not be able to afford to find the buyer, but who may 
5 be able to provide the buyer with the exact deal the buyer desires. For instance, this 
might be the case for a car buyer who could precisely define the car and option 
packages he wanted for a specified price. The present invention allows such a buyer to 
issue a binding purchase offer that is globally communicated to authorized dealers in the 
U.S.. Any one of those dealers could then decide whether or not to accept the offer. 

10 The buyer's advantage is particularly significant when the sellers of products sought by 
the buyer have no inventory carrying costs, as is the case with insurance sales. 
Insurance buyers could use the present invention to cast a wide net to reach thousands 
of potential insurance sellers and potentially find a seller willing to satisfy the buyer's 
specified purchase conditions. 

15 It is a goal of the present invention to provide a robust system that 

matches buyers* requirements with sellers enable of satisfying those requirements. The 
invention provides a global bilateral buyer-driven system for creating binding contracts 
incorporating various methods of communication, commerce and security for the buyer 
and the seller. The power of a central controller to field binding offers from buyers, 

20 communicate those offers globally in a format which can be efficiently accessed and 
analyzed by potential sellers, effectuate performance of resulting contracts, resolve 
disputes arising from those contracts, and maintain billing, collection, authentication, 
and anonymity makes the present invention an improvement over conventional systems. 

AGENCY-BASED SELLERS 

25 The method and apparatus of another embodiment of the present 

invention, which permits the CPO management system to accept or reject a given CPO 
on behalf of certain agency-based sellers who have delegated such authority to the CPO 
management system, will now be discussed with reference to Figures 21 through 40. 
Figure 21 shows a conditional purchase offer (CPO) management system 2100 for 

30 receiving conditional purchase offers from one or more customers or travel agents 2110, 
hereinafter referred to as customer 2110, and for evaluating the received CPOs against a 
number of CPO rules defined by a plurality of sellers, such as airlines 2120, 2130 or 
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cruise operators (not shown), to determine whether any seller is willing to accept a 
given CPO. As discussed further below, if a seller accepts a given CPO, the CPO 
management system 2100 binds the customer 2110 on behalf of the accepting seller 
2130, to form a legally binding contract. 

As used herein, a CPO is a binding offer containing one or more 
conditions submitted by a customer 21 10 for the purchase of an item, such as air travel, 
at a customer-defined price. In the illustrative airline embodiment, the customer- 
defined conditions would include itinerary parameters, such as the origin and 
destination cities; acceptable dates and times of departure and return; and whether 
connecting flights or stopovers are acceptable to the customer. In addition, the 
parameters of a CPO may allow a customer to specify one or more preferred airline(s), 
flights, seat assignments, seat class, aircraft type, refund/change rules, or maximum 
layover time. In a cruise embodiment, the customer-defined conditions would also 
include itinerary parameters, such as the origin and destination cities; acceptable dates 
and times of departure and return; as well as one or more preferred cruise operators, 
ship type, cabin class, and dining preference. 

As discussed further below, a CPO rule is a set of restrictions defined by 
a given seller, such as an airline, to define a combination of such restrictions for which 
the seller is willing to accept a predefined minimum price. In a preferred embodiment, 
the CPO rules are generated by the revenue management system 2500 of the respective 
airline or cruise operator. In alternate embodiments, the CPO rules may be generated by 
a yield management system, a profit management system, or any system that controls 
and manages inventory. 

As discussed more fully below in conjunction with Figures 25b and 39, 
the revenue management system 2500 will employ a CPO rules generation process 3900 
to generate CPO rules by evaluating current inventory, pricing and revenue information, 
as well as historical patterns and external events, to forecast future travel. Thereafter, 
the CPO rules are utilized by the CPO management system 2100 to render a decision to 
either accept, reject or counter a CPO on behalf of a particular airiine or cruise operator. 
According to a feature of the present invention, the CPO rules are dynamic in nature and 
may be updated by a given airiine or other seller, as necessary. 
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For example, a CPO rule for a given airline can specify that the airline 
will accept any CPO for travel between Newark, New Jersey (EWR) and Orlando, 
Florida (MCO) during the month of October, 1997, provided that (i) the customer 
travels between Tuesday and Thursday, (ii) the tickets are booked within 21 days of 

5 departure, (iii) the price is at least $165 per ticket, (iv) K-class inventory is available on 
all flight segments of the customer's itinerary, and (v) there are at least two (2) 
passengers travelling together. 

Although the CPO management system 2100 is illustrated herein as a 
system for selling airline or cruise tickets, the CPO management system 2100 could be 

10 utilized to sell any good or service product, such as automobiles, insurance, computer 
equipment, or hotel accommodations, as would be apparent to a person of ordinary skill. 
For a more detailed discussion of a general CPO management system for selling such 
items, see U.S. Patent Application Serial No. 08/707,660, filed September 4, 1996, the 
parent application to the present invention, which is incorporated by reference herein. It 

15 is noted that in such alternate embodiments, the revenue management system 2500, 
discussed below in conjunction with Figures 25a through 25c, may be embodied as an 
inventory management system or any other system utilized by the seller to establish 
pricing and inventory information for the respective item. 

CPO MANAGEMENT SYSTEM 

20 As shown in Figure 21, the CPO management system 2100 preferably 

includes a CPO management central server 2200 and one or more secured airiine 
servers 2300. As discussed further below in conjunction with Figure 23, each secured 
airline server 2300 may be associated with one or more airlines or cruise operators and 
each server 2300 stores, among other things, the CPO rules defined by any associated 

25 sellers, such as the airline 2120. Each secured airline server 2300 may be remotely 
located from the CPO management central server 2200, as shown in Rgure 21, or may 
be integrated with the CPO management central server 2200. In one remote 
embodiment, the secured airline server 2300 associated with each airline or cruise 
operator may be physically located at a processing facility secured by the particular 

30 airline or cruise operator, or at the physical location of a third party. In this manner, the 
airline or cruise operator can evaluate CPO rules independently. 
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The particular location of the secured airline servers 2300 will dictate the 
nature of the information that is transmitted between the airlines 2120, 2130 or cruise 
operators (not shown) and the CPO management system 2100, as would be apparent to 
a person of ordinary skill. For example, if the secured airline servers 2300 are 
integrated with the CPO management central server 2200, or are otherwise remotely 
located from the respective airlines 2120, 2130 or cruise operators (not shown), then the 
respective airline 2120, 2130 or cruise operator will transmit the CPO rules to the 
location of the airline's associated secured airline server 2300 for storage of the CPO 
rules and application of the CPO rules against each received CPO. Likewise, if the 
secured airline servers 2300 are physically located at the processing facility secured by 
the associated airline or cruise operator, then the CPO management central server 2200 
will transmit the CPOs to each airline or cruise operator for processing and the airlines 
or cruise operator will return the response for each CPO to the CPO management central 
server 2200. Thus, the CPO management system 2100 can determine if one or more 
sellers accepts a given CPO by providing the CPO to each seller and receiving an 
acceptance or rejection, or by applying the CPO to the CPO rules to render a decision to 
either accept, reject or counter a CPO on behalf of a particular seller. 

The CPO rules contain sensitive information, including price flexibility 
and available capacity, which, if known to a seller's competitors or customers, could 
dramatically impact the seller's overall revenue structure. Thus, according to a feature 
of the present invention, the CPO rules arc preferably securely stored by each airline 
server 23{K), if necessary, to prevent one seller, such as airline 2120. from accessing, 
obtaining or altering the CPO rules of another seller, such as airline 2130. In one 
embodiment, the secured airline servers 2300 utilize computer security techniques, such 
as database access control mechanisms. In this manner, the integrity and confidentiality 
of the CPO rules are maintained in the potentially hostile computing environment. 

In addition, according to a further feature of the invention, the CPO 
management system 2100 prevents customers 2110 from submitting multiple CPOs 
containing a progressively increasing price in order to identify the seller's defined 
minimum price for a given flight or berth. For example, if the CPO will be binding 
upon the customer 21 10 if accepted by any airiine 2 1 20 or cruise operator, the customer 
2100 will be discouraged from "pinging" the CPO management system 210O to identify 
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the seller's underlying price flexibility. In addition, the CPO management system 2100 
can limit the number of CPOs that any customer 21 10 can submit within a predefined 
time period. 

In alternate embodiments, the customer or travel agent 2110 can be 
5 charged a fee or a penalty if a ticket is not booked when at least one airline has accepted 
the CPO or the CPO management system 2100 can evaluate a rating of said customer 
21 10 containing information regarding the likelihood that said customer 2110 will book 
a ticket corresponding to said CPO. For a more detailed description of a suitable rating 
system, see U.S. Patent Application Serial No. 08/81 1.349, filed March 4, 1997, entitled 

10 AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 
present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of bookings to purchase offers by the customer 2110. 
In this manner, the airiine or cruise operator can be confident that if the seller accepts 
the customer's offer, the customer will book the ticket without using the information to 

15 ascertain the seller's underlying level of price flexibility. The particular location of a 
given secured airiine server 2300 may also impact the level of security measures that the 
associated airiine(s) or cruise operator(s) may desire for the sensitive CPO rules. For 
example, if a given secured airiine server 2300 is dedicated to a single airiine and is 
physically located at a processing facility secured by the associated airiine, then the 

20 respective airiine may implement its own minimal security measures to control the 
processing of each CPO against its own CPO rules, if desired, and thereby maintain the 
integrity and confidentiality of the price-sensitive information incorporated into the 
CPO rules. If, however, a given secured airiine server 2300 stores the CPO rules for a 
plurality of airiines or cruise operators and is remotely located from such airiines or 

25 cruise operators, then the importance of implementing computer security and database 
access control mechanisms may be increased, as would be apparent to a person of 
ordinary skill. 

As discussed further below, each customer 2110 contacts the CPO 
management system 2100. for example, by means of telephone, facsimile, online access, 
30 e-mail, in-person contact or through a travel agent, and provides the CPO management 
system 2100 with the terms of their CPO. It is noted that each customer 2110 may 
employ a general-purpose computer for communicating with the CPO management 
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system 2100. The general-purpose computer of each customer 2110 is preferably 
comprised of a processing unit, a modem, memory means and any software required to 
communicate with the CPO management system 2100. 

Once the terms of the CPO have been received by the CPO management 
system 2100, the CPO management central server 2200 will execute a CPO 
management process 3600, discussed below in conjunction with Figures 36a through 
36c, to compare the received CPO against the CPO rules of each airline or cruise 
operator. As a result of this comparison, the CPO is either accepted, rejected or 
countered. Thereafter, the customer 2110 is notified of the response of the airlines or 
cruise operators to the CPO. If a seller accepts the CPO, or if the customer 2110 
accepts a counteroffer from a seller, a ticket is then booked by the CPO management 
system 2100 with the appropriate restrictions which meet the conditions defined by the 
customer 2110. 

According to a further feature of the present invention, the minimum 
requirements of a CPO are designed to discourage utilization of this system by business 
travelers or last minute travelers who are typically willing to pay full-fare. For example, 
business travelers will be discouraged if the CPO rules require a Saturday night stay or 
significant flexibility by the customer 21 10 on the time of both the departure and return 
portions of the customer's itinerary. In this manner, business travelers, who are 
typically unwilling to lose up to a full day at either end of their trip, will be discouraged 
from purchasing such discounted tickets. Thus, the present invention permits airiines to 
fill otherwise empty seats in a manner that stimulates latent and unfulfilled leisure travel 
demand while leaving underlying fare structures of the airiines 2120, 2130 intact. 

Likewise, in embodiments where the CPO management system is 
utilized for the sale of any item, the minimum requirements of a CPO arc preferably 
designed to discourage utilization of this system by customers who arc typically willing 
to pay the full retail price. For example, when selling fashion items, CPO customers 
can be required to purchase fashions from the previous season. Similarly, the CPO rules 
can be designed to require the purchase of multiple quantities of a given item, and 
thereby discourage use by consumers looking for one item, who are more likely to pay 
the full rctail price. 
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In a preferred embodiment, the CPO management system 2100 may 
optionally access a central reservation system (CRS) 2400, discussed below in 
conjunction with Figure 24, to perform itinerary queries that will identify particular 
flights or berths which satisfy a given itinerary, and to make reservations. The central 
5 reservation system (CRS) 2400 may be embodied, for example, as an existing 
conventional reservation system, such as Apollo, Sabre, System One or Worldspan. 

In addition, the CPO management system 2100 could alternatively access 
the proprietary reservation systems (ARSs) 2150 of each airline or cruise operator to 
perform such itinerary queries and to make reservations with the respective airline or 
10 cruise operator. The airline reservation systems (ARSs) 2150 maintained by each 
airline 2120, are each essentially a subset of the central CRS 2400. Thus, in view of the 
overlapping functions and capabilities of the CRS 2400 and the proprietary reservation 
systems 2150 of each airline or cruise operator, the CPO management system 2100 
could access any of such systems to obtain required information, and the terms "CRS" 
15 and "ARS" are used interchangeably herein. 

As shown in Figure 21. each airline 2120. 2130 or cruise operator (not 
shown), also has a revenue management system (RMS) 2500. discussed further below in 
conjunction with Figures 25a through 25c. The RMS 2500 may be embodied as a 
conventional RMS, as modified herein to generate CPO rules and to otherwise allocate 
20 and price airline or cruise tickets for sale to CPO customers. 

Generally, the revenue management systems (RMSs) 2500 are utilized to 
optimize revenue per flight or berth, in a known manner. An RMS performs seat or 
cabin inventory control by periodically adjusting nested booking limits ("buckets") for 
the various fare classes, in order to optimize the passenger mix and thereby maximize 
25 the generated revenue. 

The CPO management system 2100. customer 21 10. airiines 2120, 2130, 
cruise operators (not shown) and central reservation system 2400 (collectively, the 
"nodes") preferably transmit digitally encoded data and other information between one 
another. The communication links between the nodes preferably comprise a cable, fiber 
30 or wireless link on which electronic signals can propagate. For example, each node may 
be connected via an Internet connection using a public switched telephone networic 
(PSTN), such as those provided by a local or regional telephone operating company. 
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Alternatively, each node may be connected by dedicated data lines, cellular. Personal 
Communication Systems ("PCS"), microwave, or satellite networks. 

Figure 22 is a block diagram showing the architecture of an illustrative 
CPO management central server 2200. The CPO management central server 2200 
preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 2205, a random access memory (RAM) 2210, a read only memory (ROM) 
2220, a clock 2225. a data storage device 2230. and communications ports 2240. 2250 
2260. The CPU 2205 is preferably linked to each of the other listed elements, either by 
means of a shared data bus. or dedicated connections, as shown in Figure 22. 

The CPU 2205 may be embodied as a single commercially available 
processor, such as Intel's Pentium 100 MHz P54C microprocessor. Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystems 166 MHz UltraSPARC ! 
microprocessor. Alternatively, the CPU 2205 may be embodied as a number of such 
processors operating in parallel. 

nie ROM 2220 and/or data storage device 2230 are operable to store one 
or more instructions, discussed further below in conjunction with Figure 36. which the 
CPU 2205 is operable to retrieve, interpret and execute. For example, the ROM 2220 
and/or data storage device 2230 preferably store processes to accomplish the transfer of 
required payments, charges and debits, between the airlines 2120. 2130 and customers 
2110. In particular, as discussed below in conjunction with Figure 36c. the CPO 
managemem process 3600 preferably transmits the credit card information associated 
with a given customer 21 10 to the credit card issuer for payment, if a ticket is actually 
issued to the customer 2110. The processing of such accounting transactions are 
preferably secured in a conventional manner, for example, using well-known 
cryptogr^hic techniques. 

The CPU 2205 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as. for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instracUons from the data storage device 2230 or ROM 2220. The ALU is 
operable to perform a plurality of operations needed to carry out instmctions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 
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As discussed further below in conjunction with Figures 26 through 29, 
respectively, the data storage device 2230 includes a customer database 2600, an airline 
database 2700, a flight schedule database 2800, and a CPO database 2900. The 
custon:)er database 2600 preferably stores information on each customer of the CPO 

5 management system 2100, including biographical information and billing information, 
such as a credit card number. The airline database 2700 preferably stores information 
on each airline which is registered with the CPO management system 2100 to sell 
airline tickets to CPO customers, including address and contact information. The flight 
schedule database 2800 preferably stores specific flight information for each O & D 

10 Pair. Finally, the CPO database 2900 preferably contains a record of each CPO being 
processed by the CPO management system 2100, including the terms of the CPO and 
the associated status. 

In addition, the data storage device 2230 includes a CPO management, 
process 3600, discussed further below in conjunction with Figure 36. Generally, the 

15 CPO management process 3600 receives each CPO from a customer 2110, compares 
the CPO against the CPO rules of each airiine 2120, 2130, and determines whether to 
accept, reject or counter the CPO on behalf of an airline. 

The communications port 2240 connects the CPO management central 
server 2200 to the central reservation system (CRS) 2400 and the proprietary 

20 reservation systems (ARSs) 2150 maintained by each airline 2120, 2130. The 
communications port 2250 connects the CPO management central server 2200 to 
individual customers and travel agents, such as the customer 2110, for example, by 
means of an Internet connection using the public switched telephone network (PSTN). 
The communications port 2260 connects the CPO management central server 2200 to 

25 any renwie secured airiine servers 2300. The communications ports 2240, 2250, 2260 
each preferably include multiple communication channels for simultaneously 
establishing a plurality of connections. It is noted that although the CPO management 
central server 2200 is illustrated as having three separate communication ports 2240, 
2250, 2260, the CPO management central server 2200 could alternatively be 

30 implemented with a single connection to an Ethernet network, which in turn provides 
the central server 2200 with a connection to the various nodes. 
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Figure 23 is a block diagram showing the architecture of an illustrauve 
secured airline server 2300. As previously indicated, the CPO management system 
2100 may utilize one or more secured airline servers 2300, each supporting one or more 
airlines 2120. 2130. Each secured airiine server 2300 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 2305, a random 
access memory (RAM) 2310. a read only memory (ROM) 2320, a clock 2325. a data 
storage device 2330. and communications ports 2340. 2345. Each of these components 
may be identical to those described above in conjunction with Figure22. 

As previously indicated, in one embodiment, the CPO rules may be 
stored in a secure database to maintain the integrity and confidentiality of the highly 
sensitive information incliided in each CPO role. Thus, the secured airiine server 2300 
preferably uses a secure database, such as the products commercially available from 
Oracle, Informix or IBM. 

As discussed further below in conjuncUon with Figures 30 through 32. 
respectively, the data storage device 2330 includes a secured airiine rules database 
3000. a counteroffer rules database 3100. and a secured airiine audit database 3200. 
The secured airiine rales database 3000 preferably maintains the CPO rules for the one 
or more airiines associated with the secured airiine server 2300. The counteroffer roles 
database 3100 is preferably stored by each secured airiine server 2300 to maintain a set 
of tolerances which may be uUlized by the CPO management system 2100 to generate a 
counteroffer to a CPO on behalf of an airiine. if the CPO is within predefined tolerances 
of one or more restrictions associated with a given CPO rale. As previously indicated, 
the secured airiine rules database 3000 and the counteroffer rales database 3100 may be 
stored in an encrypted format to maintain the integrity and confidenUality of the highly 
sensitive information included in the CPO rales. The secured airiine audit database 
3200 preferably maintains an audit trail for each CPO that is processed by the CPO 
management system 2100. 

In addition, the data storage device 2330 includes an evaluation process 
3700 and an audit process 3800. discussed further below in conjunction with Figures 37 
and 38. respectively. Generally, the evaluation process 3700 is a subroutine executed 
by the CPO management process 3600, which receives a CPO and compares the CPO 
against the rales of one airline, such as the airiine 2120, to generate a response on behalf 
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of the airline to the given CPO. The audit process 3800 is a subroutine executed by the 
CPO management process 3600 to maintain an audit trail for each CPO that is processed 
by the CPO management system 2100. 

The communications port 2340 connects the secured airline server 2300 
5 to the CPO management central server 2200. The communications port 2345 connects 
the secured airline server 2300 to the associated airlines(s) 2120. The communications 
ports 2340, 2345 preferably include multiple communication channels for 
simultaneously establishing a plurality of connections. 

CENTRAL RESERVATION SYSTEM 

^0 Figure 24 is a block diagram showing the architecture of an illustrative 

central reservation system (CRS) server 2400. The CRS 2400 preferably includes 
certain standard hardware components, such as a central processing unit (CPU) 2405, a 
random access memory (RAM) 2410. a read only memory (ROM) 2420, a clock 2425, a 
data storage device 2430, and a communications port 2440. Each of these components 

15 may be identical to those described above in conjunction with Figure 22. 

The ROM 2420 and/or data storage device 2430 are operable to store one 
or more instructions, for processing (1) flight information received from the airlines; (2) 
itinerary inquiries regarding flight availability; and (3) ticket bookings, in a known 
manner, which the CPU 2405 is operable to retrieve, interpret and execute. 

20 As discussed further below in conjunction with Figures 28, 33 and 34, 

respectively^ the data storage device 2430 includes a flight schedule database 2800, a 
pricing and restrictions database 3300, and a seat allocation database 3400. As 
previously indicated, the flight schedule database 2800 contains essentially the same 
flight information as the database of the same name which is stored by the CPO 

25 management central server 2200, namely, specific flight information for each O & D 
Pair. The pricing and restrictions database 3300 maintains pricing information and 
related restrictions for each fare class on a given flight offered by the airiines 2120, 
2130. The seat allocation database 3400 maintains available inventory information for 
each fare class on a given flight offered by the airiines 2120, 2130. 

30 The communications port 2440 connects the CRS 2400 to the CPO 

management central server 2200 and to each airiine, such as the airiines 2120, 2130. 
The CRS 2400 preferably includes an electronic mail processor 2450 for processing and 
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storing e-mail messages transmitted between the CRS 2400 and the various customers 
21 10, airlines 2120, 2130 and the CPO management system 2100. 

REVENUE MANAGEMENT SYSTEM 
Figure 25a is a block diagram showing the architecture of an illustrative 
5 revenue management system (RMS) 2500, as maintained by each airline, such as the 
airline 2120. As previously indicated, the RMS 2500 may be embodied as a 
conventional RMS, such as an RMS commercially available from Sabre Decision 
Technologies, as modified herein to generate CPO rules and to otherwise allocate and 
price airline tickets for sale to CPO customers. In this manner, the RMS 2500 makes a 

10 portion of the inventory of an airline 2120 available for sale to CPO customers 21 10. It 
is noted that the RMS for many airlines performs only the function of inventory 
allocation and does not incorporate a pricing function. In such cases, a separate system, 
such as a manual process, is utilized to price inventory that has been allocated by the 
RMS. In the illustrative embodiment disclosed herein, the RMS 2500 performs both the 

15 inventory allocation and pricing functions. 

The RMS 2500 preferably includes certain standard hardware 
components, such as a central processing unit (CPU) 2505, a random access memory 
(RAM) 2510, a read only memory (ROM) 2520, a clock 2525, a data storage device 
2530, and a communications port 2540. Each of these components may be identical to 

20 those described above in conjunction with Figure 22. 

Tlie ROM 2520 and/or data storage device 2530 are operable to store one 
or more instructions, for analyzing current seating inventory and revenue, as well as 
historical patterns, to allocate and price available seat inventory in an effort to maximize 
revenue for the airiine, which the CPU 2405 is operable to retrieve, interpret and 

25 execute. 

As discussed further below in conjunction with Figures 33 through 35, 
respectively, the data storage device 2530 includes a pricing and resuictions database 
3300. and a seat allocation database 3400, which each contain essentially the same 
information as the databases of the same name stored by the CRS 2400. as well as a 
30 forecast and demand analysis database 3500. As previously indicated, the pricing and 
restrictions database 3300 maintains pricing information and related restrictions for each 
fare class on a given flight offered by the associated airiine 2120, and the seat allocation 
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database 3400 maintains available inventory information for each fare class on a given 
flight offered by the associated airline 2120. The forecast and demand analysis database 
3500 contains informaUon on each selling price for each fare class for a given flight, 
and the forecasted demand at each selling price as established by the RMS 2500. In 
addition, the data storage device 2530 preferably includes a CPO rules generation 
process 3900. discussed below in conjunction with Figure 39, to generate CPO rules by 
evaluating current inventory, pricing and revenue information. a.s well as historical 
patterns, to forecast future travel. 

The communications port 2540 connects each RMS 2500 to the CRS 
2400 and the CPO management system 2100. 

Figure 25b illustrates the manner in which the RMS 2500 utilizes a 
number of databases and other tools in implementing a conventional pricing and 
allocation process and the CPO mles generation process 3900. The particular format 
and content of the illustrative databases shown in Figure 25b are discussed in detail 
below in conjunction with Figures 33 through 35. It is noted that the conventional 
pricing and allocation process and the CPO rules generation process 3900 may be 
executed by the RMS 2500 initially when a flight is first added to the flight schedule, 
and then periodically to reallocate and price available inventory in response to demand 
and external events. 

Thus, when a flight is first added to the flight schedule of an airline 2120, 
a record of the flight is preferably created by the airline reservation system 2150 in the 
flight schedule databa.se 2800 with the appropriate itinerary information. In addition, 
the RMS 2500 will perform a conventional pricing and allocation process in conjunction 
with the CPO rules generation process 3900, shown in Figure 39, to initially populate 
the respective fields of the pricing and restrictions database 3300. seat allocation 
database 3400. and forecast and demand analysis database 3500 for the flight, as shown 
in Figure 25b. 

Generally, during the initial pricing and allocation process for a given 
flight, the RMS 2500 attempts to maximize revenue by establishing a plurality of fare 
classes and allocating the number of seats and price assigned to each fare class. The 
initial seat allocation and pricing information is stored in the seat allocation database 
3400 and the pricing and restrictions database 3300, respectively. The initial price for 
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each fare class and the forecasted demand is preferably stored in the forecast and 
demand analysis database 3500. In one embodiment, a separate fare class can be 
established by the RMS 2500 for selling tickets to CPO customers. Since tickets to 
CPO customers arc generally sold at a discount, the RMS 2500 preferably only initially 
allocates seats to the CPO fare class which arc forecasted to be empty or unlikely to be 
sold when the flight actually departs. As is well known, an airline can utilize a 
convenUonal RMS 2500 to predict, based on available historical data, whether or not 
therc will be empty seats on a given flight. 

As shown in Figure 25b. the airline reservation system (ARS) 2150 will 
access the established pricing and restrictions database 3300 and .scat allocation 
database 3400 to perform itinerary queries. In addition, as tickets are sold by the airiine 
2120, the ARS 2150 will preferably decrement the available inventory in the seat 
allocation database 3400. In this manner, the seat allocation database 3400 maintains an 
up-to-date representation of the available inventory on each flight 

The RMS 2500 will continue to monitor the actual demand 2560 within 
each fare class relative to forecasted demand 2570. as illustrated by Figure 25c, 
dynamically reevaluating the inventory allocation and pricing of each fare class for a 
given flight in order to minimize the unanticipated excess inventory delta 2580. The 
RMS 2500 monitors current actual demand information by retrieving detailed inventory 
data from the seat allocation database 3400 or sununary information from the forecast 
and demand analysis database 3500. In addition, the RMS 2500 will utilize the 
historical demand information stored in the forecast and demand analysis database 3500 
for prior periods, which essentially provides a demand curve for each selling price of a 
given fare class on each flight. For example, when allocating and pricing inventory for 
a given flight, the RMS 2500 may analyze demand trends for simUar flights from 
previous relevant time periods, in a known manner. It is also noted that conventional 
RMSs typically respond to competitive forces and other external events, such as price 
wars or increased demand due to a large event, such as the Olympics, as shown in 
Figure 25b. 

According to a feature of the present invention, an airiine 2120 can 
correct for forecasung errors, if necessary, or other compeUtive forces which have 
produced unanticipated excess capacity 2580, by releasing tickets for sale to CPO 
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customers. Due to the confidential nature of the CPO rules, and the discouraged use of 
CPO tickets by full-fare business travelers, the airlines 2120, 2130 can sell such excess 
capacity at a discount, without undermining its existing published fare structure. Thus, 
in a preferred embodiment, the RMS 2500 will periodically execute the CPO rule 
5 generation process 3900, discussed below in conjunction with Figure 39, to generate 
CPO rules that encourage the sale of tickets to CPO customers. 

DATABASES 

Figure 26 illustrates an exemplary customer database 2600 that 
preferably stores information on each customer of the CPO management system 2100, 

10 including biographical information and billing information, such as a credit card 
number. The customer database 2600 maintains a plurality of records, such as records 
2605-2615, each associated with a different customer. For each customer name listed in 
field 2640, the customer database 2600 includes the customer*s address in field 2645 
and credit card number in field 2655. In addition, the customer account database 2600 

15 preferably includes an identification (ID) number in field 2660. The ID number stored 
in field 2660 may be utilized, for example, to index a historical database (not shown) of 
previous ticket purchases and CPOs associated with the customer. 

Figure 27 illustrates an exemplary airline database 2700 which 
preferably stores information on each airline which is registered with the CPO 

20 management system 2100 to sell airiine tickets to CPO customers, including address 
and contact information. The airline database 2700 maintains a plurality of records, 
such as records 2705-2715, each associated with a different airiine. For each airiine 
name listed in field 2740, the airiine database 2700 includes address and contact 
information in fields 2745 and 2750. respectively. The contact information may 

25 comprise, for example, the name of an individual employee of the airline 2120 and a 
corresponding telephone number, web page URL, bulletin board address, pager number, 
telephone number, electronic mail address, voice mail address or facsimile number. 

In addition, in an embodiment where the CPO rules of a given airiine are 
stored in an encrypted format, the cryptographic key of the associated airiine is 

30 preferably stored in field 2755 of the airiine database 2700. Finally, the airiine database 
2700 preferably stores an indication in field 2760 of the percentage of CPOs which have 
been offered to each airiine which have actually been accepted by the respective airiine. 
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In this manner, the CPO management system 2100 can offer a particular CPO to airlines 
in a sequence that is ranked in accordance with the CPO acceptance rate, as discussed 
further below in conjunction with Figure 36b. In alternate embodiments, the airline 
database 2700 can incorporate fields to facilitate the processing of CPOs in accordance 
with sequences based on (i) the amount of inventory made available by each airline for 
sale to CPO customers, (ii) priorities negotiated by each airline, such as an airline 
priority over certain routes, or (iii) die highest commission rates paid by the airlines to 
the CPO management system 2100. 

Figure 28 illustrates an exemplary flight schedule database 2800 that 
preferably stores specific fiight information for each O & D Pair, as well as connection 
information. The flight schedule database 2800 maintains a plurality of records, such as 
records 2805-2815. each associated with a different flight. For each O & D Pair listed 
in fields 2840 and 2845, the flight schedule database 2800 includes the date of each 
flight in field 2850, as well as the times of departure and arrival of the respective flight 
in fields 2855 and 2860. The airiine and flight number associated with each flight are 
preferably indicated in fields 2865 and 2870, respectively, and any required connections 
are indicated in field 2875. 

Figures 29a and 29b illustrate an exemplary CPO database 2900 which 
preferably contains a record of each CPO being processed by the CPO management 
system 2100, including the terms of the CPO and the associated status. The CPO 
database 2900 maintains a plurality of records, such as recoixls 2905 and 2910. each 
associated with a different CPO being processed by the system 2100. For each CPO 
identified by CPO number in field 2920. die CPO database 2900 includes the date the 
CPO was received in field 2925, and an identification (ID) number for the travel agent, 
if any. associated with the CPO in field 2930. It is noted that the travel agent ID 
number stored in field 2930 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the travel agent. 

In addition, the CPO database 2900 identifies the customer by name in 
field 2935, and by identification number in field 2940 and identifies any companion 
passengers in field 2945. The ID number stored in field 2945 is preferably utilized to 
cross-reference the corresponding information stored for the customer in the customer 
database 2600. 



69 



wo 98/10961 



PCT/US97/1S492 



The parameters of the customer's itinerary and other pertinent restrictions 
are stored in fields 2950 through 2995 of the CPO database 2900. Specifically, the 
origin and destination cities are identified in fields 2950 and 2955, respectively, and any 
connection restrictions specified by the customer 21 10 are recorded in field 2960. The 
5 dates of the customer's departure and return are stored in fields 2965 and 2970. 
respectively. In an alternate embodiment (not shown), the CPO databa.se 2900 could 
also permit the customer 21 10 to specify particular time-of-day (range) restrictions for 
the departure and return flints. 

The CPO database 2900 preferably stores an indication of the total 

10 number of passengers traveling togetfier in field 2975, and sets forth the price the 
customer is willing to pay per ticket in field 2980. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 2985, such as preferred airiine(s), 
flights, or seat assignments. Field 2990 records the current status of the respective 
CPO. such as pending, accepted, rejected or expired. Finally, if the CPO ultimately 

15 results in a ticket being booked for the customer, the passenger name record number 
(PNR) associated with the ticket is stored in field 2995. Generally, a PNR is a record 
stored by the CRS 2400 containing information for each ticketed passenger, including: 
record number, passenger name(s), address for ticketing, billing information, such as 
credit card number, carrier(s) and flight number(s) for all segments, seat assignments, 

20 inventory class, aircraft type, airline-issued auriiorization code for discounted fare, 
selling price, and additional comments. 

As discussed further below, rather than reject a CPO, one or more 
airiines may issue a binding counteroffer to the CPO, which the customer 2110 may 
accept or reject. If a counteroffer is issued to a customer 21 10, then a record of the 

25 counteroffer with any associated restrictions, is preferably created in the CPO database 
2900. For example, if an airline 2120 issues a counteroffer to the CPO number 23456 
stored in record 2905 of the CPO database 2900, then the status of the initial CPO is 
changed to "counter", and a fiuther record (not shown) corresponding to the 
counteroffer may be stored in the CPO database 2900 under a modified CPO number 

30 indicating the counteroffer, such as CPO number 23456-CO 1 . 

Figure 30a illustrates an exemplary secured airiine rules database 3000 
which preferably maintains the CPO rales for one or more airiines associated with a 
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particular secured airline server 2300. As previously indicated, the secured airline rules 
database 3000 may be stored in an encrypted format to maintain the integrity and 
confidentiality of the highly sensitive information included in the CPO rules. The 
secured airline rules database 3000 maintains a plurality of records, such as records 
5 3002 and 3004, each associated with a different CPO rule. For each CPO rule identified 
by rule number in field 3010, the secured airline rules database 3000 includes the 
associated restrictions defined by the respective airline in fields 3012 through 3044. 

According to a feature of the invention, the CPO rules that arc processed 
by the CPO management system 2300 may be of varying complexity. The particular 

10 restrictions set forth in the illustrative secured airline rules database 3000 are 
representative of the principles of the invention only. An airline can incorporate a 
subset of such restrictions and/or incorporate additional restrictions, as would be 
apparent to a person of ordinary skill. For example, the CPO rules of an airiine 2120 
may also incorporate restrictions on the minimum number of nights associated with the 

15 itinerary, or require the customer 2 1 1 0 to have a Saturday night stay. 

For illustrative purposes, the secured airline rules database 3000 shown 
in Figure 30a, allows an airiine to create CPO rules by specifying some or all of the 
following restrictions in fields 3012 through 3044: origin and destination cities, 
connection restrictions, fiight numbers included or excluded, dates and times of 

20 departure, departure days of the week, dates and times of return, return days of the 
week, number of passengers traveling, length of haul, average yield per seat, minimum 
price per ticket, inventory restrictions or seat availability, and advance purchase 
requirements. 

For example, record 3002, shown in Figure 30a, is associated with a 
25 CPO rule for a given airline which specifies that the airiine will accept any CPO for 
travel from Newaric, New Jersey (EWR) to Oriando, Florida (MCO) during the month 
of October, 1997, provided that (i) the customer travels on any flight departing on a 
Tuesday through Thursday, (ii) the tickets are booked within 21 days of departure, (iii) 
the price is at least $165 per ticket, (iv) K inventory is available on all flight segments of 
30 the customer's itinerary and (v) at least two (2) passengers are travelling together. 

Similariy, record 3004, shown in Figure 30a, is associated with a CPO 
rule for a given airiine which specifies that the airiine will accept any CPO having a 
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price of at least $150, for two or more people traveling together between New York, NY 
(JFK) and Chicago, IL (ORD) during April or May. 1997 where Q or K inventory is 
available on any flight between 1 1 a.ra. and 2 p.m.. where the flight departs on a 
Tuesday and returns on a Monday through Thursday, and is booked between 7 and 21 
5 days prior to travel and can be routed through the airiine's Cleveland. OH or Pittsburgh. 
PA hubs. 

In an alternate or supplemental embodiment, the secured airline rules 
database 3000 can be implemented using a pair of inventory and pricing databases 3050, 
3075, illustrated in Figures 30b and 30c, respectively. In this embodiment, the CPO 

10 rules stored in the inventory database 3050 contain actual inventory on each flight that 
the airiine has released for sale to CPO customers. The inventory database 3050 
maintains a plurality of records, such as records 3052-3056, each associated with a 
different CPO rule and flight. For each CPO rale identified by rule number in field 
3060, the inventory database 3050 includes an indication of the airiine, flight number 

15 and dates in fields 3062 through 3066. respectively. In addition, the number of seats 
that may be sold by the CPO management system 2100 on each flight is indicated in 
field 3068. In a preferred embodiment, as inventory is sold by the CPO management 
system 2100, die available inventory recorded in the inventory database 3050 will be 
decremented. 

20 The pricing database 3075, shown in Figure 30c, maintains a plurality of 

records, such as records 3080-3084, each associated with a different O & D Pair, For 
each O & D Pair identified in fields 3090 and 3092, respectively, the pricing database 
3075 includes an indication of the airiine, dates and minimum price in fields 3088, 3093 
and 3096, respectively. 

25 Thus, in such an alternate or supplemental embodiment, prior to 

accessing the inventory database 3050, the CPO management system 2100 will 
preferably query the CRS 2400 to identify possible flights which satisfy the customer's 
itinerary restrictions. Thereafter, the CPO management system 2100 will access the 
inventory database 3050 to determine if the airiine has released any inventory on such 

30 identified flights to the CPO management system 2100 for sale to CPO customers. In 
one embodiment, the list of identified flights from the CRS 2400 can be sequenced to 
optimize customer preferences, and the inventory database 3050 can be searched in the 
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order of the sequenced list of flights, until available inventory is identified. Finally^ if 
any available inventory satisfying the customer's itinerary is identified, then the CPO 
management system 2100 will access the pricing database 3075 shown in Figure 30c, to 
determine if the price specified by the customer exceeds the minimum price defined by 
5 the airline, as set forth in field 3096 of the pricing database 3075. 

Figure 31 illustrates an exemplary counteroffer mles database 3100 
which preferably stores a set of tolerances which may be utilized by the CPO 
management system 2100 to generate a counteroffer to a CPO if the CPO is within 
predefined tolerances of one or more restrictions associated with a given CPO rule. 

10 The counteroffer rules database 3100 maintains a plurality of records, such as records 
3105 and 31 10, each associated with a different CPO rule. For each CPO rule identified 
by rule number in field 3120, the counteroffer rules database 3100 includes acceptable 
tolerances on the dates and times of departure and return in fields 3125 through 3140. 
In addition, the counteroffer rules database 3100 includes tolerances on the number of 

15 passengers traveling, length of haul and yield in fields 3145 through 3155, respectively. 
Finally, the counteroffer rules database 3100 records any permissible tolerances on the 
minimum price and advance purchase requirements in fields 3160 and 3165, 
respectively. 

As shown in Figure 31, the counteroffer rules database 3100 includes 
20 counteroffer rule number 45687 in record 3105, corresponding to CPO rule number 
45687 from Figure 30a. As illustrated in Figure 31, the CPO management system 2100 
is authorized to generate a counteroffer on behalf of an airline 2120 associated with 
CPO rule number 45687, if a given CPO fails to meet one or more of the restrictions of 
CPO rule number 45687, but the restrictions which are not met are within the 
25 predefined tolerances set forth in the counteroffer rules database 3100. For example, if 
a given CPO includes a customer-defined price of $140.00, but all other airline-defined 
restrictions of CPO rule number 45687 are met, a counteroffer should be generated 
containing a price of $150.00 since the price variation is within ten percent (10%) of the 
minimum price associated with CPO rule number 45687, as authorized by counteroffer 
30 rule number 45687. 

Figure 32 illustrates an exemplary secured airiine audit database 3200 
which preferably maintains an audit trail for each CPO which is processed by the CPO 
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management system 2100. The secured airline audit database 3200 maintains a 
plurality of records, such as records 3205-3215. each associated with a different CPO 
that has been processed by the CPO management system 2100. For each CPO 
identified by CPO number in field 3220. the .secured airline audit database 3200 
includes the response of the respective airline to the CPO in field 3225. and the date and 
time of the CPO in fields 3230 and 3235. respectively. In addition, if a ticket is booked 
for the customer 21 10 on any airline, then the secured airline audit database 3200 
preferably stores the passenger name record (PNR) number associated with the ticket in 
field 3240 and an indication of whether or not the ticket was booked on the respective 
airline in field 3245. In a preferred embodiment, the entry in field 3245 indicates 
whether die ticket was booked (a) on the respective airline associated with the database, 
(b) with another airline or (c) if no ticket was issued at all. In this manner, the CPO 
management system 2100 can establish that a ticket was actually booked for each CPO 
which was accepted by at least one airline. 

Figure 33 illustrates an exemplary pricing and restrictions database 3300 
which maintains pricing information and related restrictions for each flight offered by 
the airlines 2120, 2130, as established and updated by the RMS 2500. The pricing and 
restrictions database 3300 includes a plurality of records, such as records 3305-3315, 
each associated with a different flight. For each flight identified by flight number in 
field 3325. the pricing and restrictions database 3300 includes the date of the flight in 
field 3330 and the respective price and restrictions associated with each inventory class 
in fields 3335 through 3350. 

Figure 34 illustrates an exemplary seat allocation database 3400 which 
maintains available inventory information for each fare class on a given flight offered 
by the airiines 2120. 2130. as allocated and updated by the RMS 2500. In addition, as 
inventory is sold by an airline, the airline's ARS 2150 will preferably decrement the 
available inventory recorded in the seat allocation database 3400. The seat allocation 
database 3400 includes a plurality of records, such as records 3405-3420, each 
associated with a different flight. For each flight identified by flight number in field 
3425. the seat allocation database 3400 includes the departure date of the flight in field 
3430 and the respective inventory available in each inventory class in fields 3435 
through 3440. In addition, the seat allocation database 3400 preferably includes an 
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indication of the total number of seats booked on the flight in field 3445 and total 
capacity available on the flight in field 3450. 

Figure 35 illustrates an exemplary forecast and demand analysis database 
3500, which records each selling price for each fare class for a given flight, and the 
forecasted demand at each selling price as established by the RMS 2500. As previously 
indicated, when a flight is first added to the flight schedule of an airiine 2120, a record 
of the initial price for each fare class and the forecasted demand is preferably created in 
the forecast and demand analysis database 3500. In addition, new records are 
preferably created for each new selling price that is established for each fare class by the 
RMS 2500, as part of the dynamic inventory reallocation process. 

The forecast and demand analysis database 3500 includes a plurality of 
records, such as records 3505-3525, each associated with a different selling price for a 
given fare class on a given flight. For each flight number identified in field 3530, the 
forecast and demand analysis database 3500 includes the departure date, and origin and 
destination cities in fields 3535 through 3545, respectively, and the corresponding 
offered prices and fare classes in fields 3550 and 3555, respectively. Finally, the 
forecast and demand analysis database 3500 preferably records the actual quantity of 
tickets sold by the airline at each offered price for each fare class in field 3560 and the 
corresponding forecasted quantity in field 3565. The actual quantity of tickets sold may 
be recorded in field 3560 in real-time as tickets are actually sold or by means of batch 
processing on a periodic basis. 

PROCESSES 

As discussed above, the CPO management central server 2200 preferably 
executes a CPO management process 3600, shown in Figures 36a through 36c, to 
receive each CPO from a customer 21 10 and to compare the CPO against die rules of 
each airiine in order to determine whether to accept, reject or counter the CPO on behalf 
of an airiine. As illustrated in Figure 36a, the CPO management process 3600 begins 
the processes embodying the principles of the present invention during step 3604, when 
a customer or travel agent accesses the CPO management system 2100. 

Thereafter, during step 3608, the CPO management central server 2200 
will receive the customer information, itinerary, price and other restrictions from the 
customer 2110 which are required to populate the customer database 2600, if required 
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for a new customer, and the CPO database 2900. A record of the CPO is preferably 
created in the CPO database 2900 with the received information during step 3612. and 
with the status field set to "pending." 

Appropriate legal language is preferably displayed or read to the 
customer 21 10 during step 3616, and the CPO management system 2100 will wait for 
an acknowledgment from the customer 2110 to form a binding conditional purcha-se 
offer (CPO). The price is extracted from field 2980 of the CPO database 2900 and the 
appropriate customer information, including credit card number, is extracted from the 
customer database 2600 during step 3620. Thereafter, the merchant ID associated with 
the CPO management system 2100. together with an appropriate billing descriptor, the 
total purchase amount (preferably equal to the price specified by the customer 21 10) 
and the credit card information, are transmitted to the credit card issuer during step 3624 
for pre-authorization. 

A test is then preferably performed during step 3628 to determine if an 
authorization code has been received from the credit card issuer. If it is determined 
during step 3628 that the credit card issuer has not authorized the purchase amount, then 
another credit card is preferably requested from the customer 21 10 during step 3632 and 
program control returns to step 3624 to continue processing in the manner described 
above. 

If. however, it is determined during step 3628 that the credit card issuer 
has authorized the purchase amount, then the CPO is accepted for processing during 
step 3636 and program control continues to step 3640 (Figure 36b). The CPO 
management process 3600 preferably executes the evaluation process 3700. discussed 
below in conjunction with Figure 37. for each airiine during step 3640. The CPO record 
created during step 3612 is passed to the evaluation process 3700 for comparison 
against the CPO rules of one airiine. such as the airiine 2120. to generate a response for 
the airiine to the given CPO. As previously indicated, the airiine's response to a CPO 
may be to accept, reject or counter the CPO. As discussed further below, the evaluation 
process 3700 will return the airiine's response to the CPO, as well as a flight number if 
the CPO is accepted or countered by the airiine. 

In an alternate embodiment, the evaluation process 3700 can be 
performed for each airiine in a predefined sequence until one airiine accepts the CPO. 
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For example, the evaluation process 3700 can be performed in sequence based upon (i) 
the amount of inventory made available by each airline for sale to CPO customers, (ii) 
the CPO acceptance rate of each airline, as recorded in the airline database 3700. (iii) 
priorities negotiated by each airline, such as an airline priority over certain routes, or 
(iv) the highest commission rates paid by the airlines to the CPO management system 
2100. In this manner, the sequence can be determined by factors that incent 
panicipaiion by the airlines, and/or by factors that optimize revenue to the CPO 
management system 2100. It is noted that in the preferred embodiment, the customer 
2110 will pay the price defined by the customer if the CPO is accepted by an airline, 
regardless of the minimum price the airline would be willing to accept or whatever 
sequencing criteria is utilized by the CPO management system 2100 to process the 
CPO. 

As shown in Figure 36b. a test is preferably performed during step 3644 
to determine if the CPO was accepted by at least one airiine. If it is determined during 
step 3644 that the CPO was accepted by at least one airiine then a further test is 
preferably perf'ormed during step 3648 to determine if the CPO was accepted by more 
than one airiine. If it is determined during step 3648 that the CPO was not accepted by 
more than one airiine then program control proceeds directly to step 3672 (Figure 36c) 
to book the ticket. 

If, however, it is determined during step 3648 that the CPO was accepted 
by more than one airiine. then a tie breaker algorithm is preferably executed during step 
3652 to determine which airiine acceptance to utilize. For example, the tie breaker 
algorithm can select an airiine offering an itinerary which maximizes the convenience to 
the customer 2110. maximizes the profit to the CPO management system 2100 or 
optimizes the inventory available for sale by the CPO management system 2100. It is 
noted that in the alternate embodiment, where the evaluation process 3700 is performed 
for each airiines in a predefined sequence until one airiine accepts the CPO, a tie 
breaker algorithm will not be required. In a further alternate embodiment, the customer 
21 10 may select for himself which airiine acceptance to utilize. Thereafter, program 
control proceeds to step 3672 (Figure 36c) to book the Ucket. 

In order to book the ticket, the information required to create a passenger 
name record (PNR) is extracted from the customer database 2600, the CPO database 
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2900 and the inventory and flight information received from the evaluation process 
3700 or CRS 2400. As previously indicated, a PNR generally includes the following 
parameters: record number, passenger name(s), address for ticketing, billing 
information, such as credit card number, flight numbcr(s) for all segments, carrier(s), 

5 seat assignments, inventory class, aircraft type, airline-issued authorization code for 
discounted fare, selling price, and additional comments. 

Thereafter, during step 3674, the PNR is transmitted to the airline 
reservation system 2150 of the airline upon which the ticket will be booked or the CRS 
2400 to establish a reservation. The CPO management process 3600 will then transmit 

10 the merchant ID associated with the CPO management system 2100, together with an 
appropriate billing descriptor, the total purchase amount (preferably equal to the price 
specified by the customer 2110) and the credit card information, to the credit card issuer 
during step 3678 for payment. 

The record of the CPO in the CPO database 2900 is updated during step 

15 3682 with the assigned PNR number and the status field is changed to "accepted." 
Finally, an audit process 3800, discussed below in conjunction with Figure 38, is 
executed by the CPO' management process 3600 during step 3686 for each airline to 
maintain an audit trail for each CPO which is processed by the CPO management 
system 2100. As previously indicated, the audit process 3800 will create an entry in the 

20 secured airline audit database 3200 which can be utilized to establish that a ticket was 
actually booked by the CPO management system 2100 for each CPO which was 
accepted by at least one airline. 

If, however, it was determined during step 3644 {Figure 36b) that the 
CPO was not accepted by at least one airline, then a further test is performed during step 

25 3656 to determine if at least one airline provided a counteroffer to the CPO. If it is 
determined during step 3656 that at least one airline did provide a counteroffer to the 
CPO, then the status of the initial CPO is changed to "counter", and a record of the 
counteroffer is preferably created in the CPO database 2900 during step 3660, for 
example using the original CPO number with a "-CO" extension. Thereafter, the 

30 counteroffcr(s) are transmitted to the customer 2110 during step 3664. In an alternate 
embodiment, if the CPO is within predefined tolerances, rather than receiving one or 
more counteroffers^ the customer 2110 can be instructed to resubmit the CPO at a later 
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time, or the CPO management system 2100 can periodically reexecute the CPO until the 
CPO is accepted or until the CPO expires. It is noted that in view of the dynamic nature 
of the CPO rules, a CPO that is initially rejected may be subsequently accepted by one 
or more airlines. 

5 A test is then preferably performed during step 3668 to determine if the 

customer 21 10 accepted one of the counteroffer(s). If it is determined during step 3668 
that the customer 2110 did accept a counteroffer, then p«,gram control proceeds to .step 
3672 (Figure 36c) to book the ticket, in the manner described above. If. however, it is 
determined during step 3668 that the customer 21 10 did not accept a counteroffer, then 
10 program control proceeds to step 3696 (Figure 36c), where the CPO management 
process 3600 will transmit the customer's rejection of the counteroffer to the airline(s) 
making the counteroffer. Thereafter, during step 3698. the CPO management process 
3600 will update the status of the counteroffer associated with the CPO in the CPO 
database 2900 to "rejected." Program control proceeds to step 3686 in the manner 
15 described above and then terminates during step 3699. 

If, however, it was determined during step 3656 (Figure 36b) that no 
airlines provided a counteroffer to the CPO. then program control proceeds to step 3690 
(Figure 36c). where the CPO management process 3600 will transmit the rejection of 
the CPO to the customer 21 10. Thereafter, the status of the CPO in the CPO database 
20 2900 is updated to "rejected" during step 3694. Program control proceeds to step 3686 
in the manner described above and then terminates during step 3699. 

As discussed above, the CPO management process 3600 executes an 
evaluation process 3700, during step 3640. An exemplary evaluation process 3700 is 
shown in Figures 37a and 37b. In one embodiment, the evaluation process 3700 is 
25 preferably customized for each airline, so that each evaluation process 3700 receives the 
CPO record from the CPO management process 3600 in a standard format for 
comparison against the rules of the associated airiine. such as the airline 2120. and 
returns a standard response of the airiine to the CPO. such as accept, reject or counter. 
In addition, if the response of the airiine is to accept or counter the CPO. the evaluation 
30 process 3700 preferably also returns the selected flight number. 

As shown in Figure 37a. the evaluation process 3700 initially extracts the 
O & D Pair from the CPO record during step 3705 and thereafter identifies all CPO 



79 



wo 98/10361 



PCT/US97/154^ 



niles in the secured airline rules database 3000 which are pertinent to the extracted O & 
D Pair during step 3710. The customer defined restrictions from fields 2960 through 
2995 of the CPO record are then compared to the corresponding airline defined 
restrictions from fields 3016 through 3044 of the secured airline rules database 3000 

5 during step 37 1 5, for each CPO rule identified during the previous step. 

Thereafter, a test is performed during step 3720 to determine if the CPO 
satisfies at least one airline rule. For example, CPO number 23452, stored in record 
2910 of the CPO database 2900 (Figures 29a and 29b), defines an O & D Pair of New 
York (JFK) to Chicago (ORD). Thus, the evaluation process 3700 will access the 

10 secured airline rules database 3000 and identify all CPO rules for this O & D Pair. In 
the illustrative secured airline rules database 3000 shown in Figure 30a, CPO rule 
number 23452 is identified as the only rule pertinent to this O & D Pair. Thereafter, 
each of the customer defined restrictions from fields 2960 through 2995 of the CPO 
number 23452 are compared to the corresponding airline defined restrictions from fields 

15 3016 through 3044 of CPO rule number 23452. Since the customer is willing to make 
one stop (field 2960), the airline requirement of routing through Cleveland or Pittsburgh 
(field 3016) can be satisfied. In addition, the customer's dates of departure and return 
requirements (fields 2965 and 2970) satisfy the airline's dates, times and day of week 
requirements for both the departure and retum legs of the trip (fields 3020 through 

20 3032). In addition, the number of passengers traveling satisfies the airline requirement 
set forth in field 3034 and the customers price (field 2980) exceeds the airline's defined 
minimum price (field 3040). Thus, CPO number 23452 will be accepted by the airline 
associated with CPO rule number 45687, provided that Q or K inventory is available 
(field 3042) and the CPO is being processed between 7 and 21 days prior to flight (field 

25 3044). 

In one embodiment, the CPO management system 2100 allows the 
airiines 2120, 2130 to specify CPO rules in a format that accepts a given CPO, 
conditioned upon the CPO management system 2100 finding inventory available that 
meets the requirements of the airiine, as set forth in the CPO rule, and the requirements 
30 of the customer 2110, as set forth in the CPO itself. For example, CPO rule number 
23452, shown in Figure 30a, is conditioned upon Q or K inventory being available. 
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Thus, if it is determined during step 3720 that the CPO satisfies at least 
one airline rule, then a further test is preferably performed during step 3725 to 
determine if any of the satisfied rules are conditioned on inventory being available. 

If it is determined during step 3725 that none of the satisfied rules arc 
condiUoned on inventory being available, then program control proceeds direcdy to step 
3735, discussed below. If, however, it is determined during step 3725 that one or more 
satisfied rules are conditioned on inventory being available, then the CRS or ARS is 
accessed during step 3730 to identify flights, if any, with seats available and meeting the 
appropriate restrictions of both the satisfied CPO rule and the CPO. 

Thereafter, a test is performed during step 3735 to determine if mote 
than one flight satisfying the CPO has been identified. If it is determined during step 
3735 that only one satisfactory flight has been identified, then program control proceeds 
directly to step 3745 (Figure 37b). discussed below. 

If. however, it is determined during step 3735 that more than one 
satisfactory flight has been identified, then one flight is selected during step 3740 
(Figure 37b) which most closely matches the customer preferences set forth in the CPO 
or maximizes the convenience for the customer. Alternatively, each airiine 2120 can 
define its own criteria for the CPO management system 2100 to utilize to select a single 
flight. Thereafter, the response will be set to "accept" during step 3745. and program 
control will return to the CPO management process 3600 during step 3770 with the 
defined response and selected flight number. 

If. however, it was determined during step 3720 (Figure 37a) that the 
CPO does not satisfy at least one airiine rule, then program control proceeds to step 
3750 (Figure 37b), where a further test is performed to determine if the CPO is within 
tolerances specified by the airiine for generating a counteroffer. As previously 
indicated, the counteroffer rules database 3100 is preferably stored by each secured 
airiine server 2300 to maintain a set of tolerances which may be utilized by d,e CPO 
management system 2 100 to generate a counteroffer to a CPO on behalf of an airiine. if 
the CPO is within predefined tolerances of one or more restrictions associated with a 
given CPO rule. 

Thus, if it is determined during step 3750 that the CPO is within 
tolerances specified by the airiine for generating a counteroffer, then a counteroffer is 
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generated during step 3760 with the appropriate modified terms, as retrieved from the 
counteroffer rules database 3100. Thereafter, the response will be set to "counter" 
during step 3765, and program control will return to the CPO management process 3600 
during step 3770 with the defined response and selected flight number. 

If, however, it is determined during step 3750 that the CPO is not within 
tolerances specified by the airline for generating a counteroffer, then the response will 
be set to "rejected" during step 3755, and program control will return to the CPO 
management process 3600 during step 3770 with the defined response and the selected 
flight number equal to null. 

As previously indicated, the CPO management process 3600 preferably 
executes an audit process 3800 during step 3686 for each airiine to maintain an audit 
trail for each CPO that is processed by the CPO management system 2100. An 
exemplary audit process 3800 is shown in Figure 38. The audit process 3800 will 
preferably create an entry in the secured airline audit database 3200 which can be 
utilized by the CPO management system 2100 to establish that a ticket was actually 
booked by the CPO management system 2100 for each CPO which was accepted by at 
least one airiine. In this manner, the airiines 2120 can be assured that the risk of a 
customer 2110, another airiine 2130 or a third party utilizing the CPO management 
system 2100 to obtain the underiying price flexibility of the airiine 2120 is minimized. 

As shown in Figure 38, the audit process 3800 will initially decrement 
the inventory in the secured airiine mics database, if necessary, during step 3810. For 
example, inventory should be decremented only if the ticket was ultimately booked by 
the associated airline, and the CPO rule which was utilized to accept the CPO actually 
included inventory released by the airiine for sale to CPO customers, as opposed to a 
CPO rule which was conditioned upon inventory being available. 

Thereafter, the audit process 3800 preferably creates a record of the CPO 
in the secured airiine audit database 3200, during step 3815, including the CPO number, 
the PNR associated with the ticket issued by the CPO management system 2100, if any, 
to the customer 21 10, and an indication of whether the ticket, if any, was booked on the 
corresponding airline. Program control will then return to the CPO management 
process 3600 during step 3820. 
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An illustrative CPO rules generation process 3900, shown in Figure 39, 
is preferably executed by the RMS 2500 initially when a flight is First added to the flight 
schedule, and then periodically to reallocate and price available inventory in response to 
demand and external events. Thus, a test is initially performed during step 3905 to 
5 determine if the current inventory allocation by the RMS 2500 is the initial allocation 
for the flight being allocated. If it is determined during step 3905 that the current 
inventory allocation is the initial allocation for the flight being allocated, then a further 
test is performed during step 3910 to determine if the flight is predicted, using 
conventional methods, to likely depart with empty seats. 

10 If it is determined during step 3910 that the flight is not likely to depart 

with empty seats, then program control will terminate during step 3985. If, however, it 
is determined during step 3910 that the flight is likely to depart with empty seats, then 
the CPO rule generation process 3900 will preferably allocate the empty seals to a 
special fare class for CPO customers during step 3915. Thereafter, an appropriate 

15 minimum fare and other restrictions for such tickets will be established during step 
3920. 

The pricing and restrictions database 3300, seat allocation database 3400, 
and forecast and demand analysis database 3500 for the flight will be updated during 
step 3925 with the newly established fare class, the allocated inventory and the initial 
price. Thereafter, the CPO rules generation process 3900 will preferably generate a 
CPO rule containing the allocated inventory, established minimum price and other 
restrictions during step 3930 and then transmit the generated CPO rale to the associated 
secured airiine server 2300 during step 3935. Program control will then terminate 
during step 3985. 

25 If, however, it was determined during step 3905 that the current 

inventory allocation is not the initial allocation for the flight being allocated, then 
program control proceeds to step 3950 to reallocate a previous allocation for one or 
more fare classes of a given flight in order to minimize the unanticipated excess 
inventory delta 2580. Thus, a test is performed during step 3950 to determine if the 

30 forecasted demand exceeds the actual demand by more than a predefined tolerance for 
any fare class. In one embodiment, the RMS can make this determination utilizing the 
summary information recorded in fields 3560 and 3565 of the forecast and demand 
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analysis database 3500. In addition, the RMS 2500 can generate the predefined 
tolerance utilized in step 3950 by analyzing historical demand information stored in the 
forecast and demand analysis database 3500 for prior periods. 

If it is determined during step 3950 that the forecasted demand does not 
5 exceed the actual demand by more than a predefined tolerance for any fare class, then 
there is no need to reallocate the existing allocation and program control will terminate 
during step 3985. It is noted that if actual demand exceeds forecasted demand, the RMS 
2500 can remove inventory that was previously allocated for sale to CPO customers. 

If. however, it is determined during step 3950 that the forecasted demand 
10 does exceed the actual demand by more than a predefined tolerance for any fare class, 
then the RMS 2500 will preferably allocate the excess capacity, or a portion thereof, for 
sale to CPO customers during step 3955. Thereafter, an appropriate minimum fare and 
other restrictions for such tickets will be established during step 3960. 

The pricing and restrictions database 3300. seat allocation database 3400. 
15 and forecast and demand analysis database 3500 for the flight will be updated during 
step 3965 with the reallocated inventory and the established price. Thereafter, the CPO 
rules generaUon process 3900 will generate a CPO niie containing the allocated 
inventory, established minimum price and other restrictions during step 3970 and then 
transmit the generated CPO rule to the associated secured airline server 2300 during 
20 step 3980. Program control will then terminate during step 3985. 

CRUISE IMPLEMENTATION 
Although the CPO management system 2100 has been primarily 
illustrated herein as a system for selling airiine tickets, the CPO management system 
2100 could be utilized to sell cruise tickets as well, as would be apparent to a person of 
25 ordinary skill. In such an embodiment, each secured airiine server 2300 would be 
associated with one or more cruise operators, as opposed to airiines. and each secured 
server 2300 stores, among other things, the CPO rules defined by any associated cruise 
operators, in a similar manner to the secured server 2300 described above in an airiine 
implementation. 

^ addition, the revenue management system 2500 and the airiine 
reservation system 2150 would be embodied as the revenue management system and 
reservation system, respectively, of each cruise operator. The cruise revenue 
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management system establishes pricing and inventory information and generates CPO 
rules in a similar manner to the revenue management system described above in an 
airiine implementation. Similariy, the cruise reservation system performs itinerary 
queries and makes reservations with the respective cniise operator in a similar manner 
to the reservation system described above in an airiine implementation. 

Thus, the CPO management system 2100 receives CPOs from potential 
cruise travelers and evaluates the CPOs against a set of CPO rules provided by each of a 
plurality of cruise operators. An illustrative CPO database 4000 for a cruise 
implementation is illustrated in Figures 40a and 40b. The CPO database 4000 
preferably stores a record of each CPO being processed by the CPO management 
system 2100. including the terms of the CPO and the associated status. The CPO 
database 4000 maintains a plurality of records, such as records 4005 and 4010. each 
associated with a different CPO being processed by the system 2100. For each CPO 
identified by CPO number in field 4020. the CPO database 4000 includes the date the 
CPO was received in field 4025, and an identification (ID) number for the travel agent, 
if any. associated with the CPO in field 4030. It is noted that the travel agent ID 
number stored in field 4030 may be utilized, for example, to index a historical database 
(not shown) of previous ticket purchases and CPOs associated with the travel agent. 

In addition, the CPO database 4000 identifies the customer by name in 
field 4035. and by identification number in field 4040. Any companion passengers are 
identified in field 4045. The ID number stored in field 4040 is preferably utilized to 
cross-reference the corresponding information stored for the customer in the customer 
database 2600. 

The parameters of the customer's itinerary and other pertinent restrictions 
are stored in fields 4050 through 4085 of the CPO database 4000. Specifically, the 
origin and destination ports arc idenUfied in fields 4050 and 4055, respecuvely, and any 
port restrictions specified by the customer 2110 are recorded in field 4060. The 
departure and return dates are stored in fields 4065 and 4070, respectively. 

The CPO database 4000 preferably stores an indication of the total 
number of passengers traveling together in field 4075. and sets forth the price the 
customer is willing to pay per ticket in field 4080. Any other miscellaneous restrictions 
specified by the customer will be recorded in field 4085. such as prefeired cruise 
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operator(s), berths, cabin assignments or meal limes. Field 4090 records the current 
status of the respective CPO, such as pending, accepted, rejected or expired. 

An illustrative secured mles database 4100 for a cruise implementation is 
shown in Figure 41 for maintaining the CPO rules for one or more cruise operators 
associated with the respective secured server 2300. The secured rules database 4100 
may be stored in an encrypted format to maintain the integrity and confidentiality of the 
highly sensitive information included in the CPO rules. The secured rules database 
4100 maintains a plurality of records, such as records 4102 and 4104, each associated 
with a different CPO mle. For each CPO rule identified by rule number in field 41 10, 
the secured rules database 4100 includes the associated restrictions defined by the 
respective cruise operator in fields 4112 through 4144. 

According to a feature of the invention, the CPO rules that are processed 
by the CPO management system 2100 may be of varying complexity. The particular, 
restrictions set forth in the illustrative secured rules database 4100 are representative of 
the principles of the invention only. A cruise operator, airline or other seller can 
incorporate a subset of such restrictions and/or incorporate additional restrictions, as 
would be apparent to a person of ordinary skill. 

For illustrative purposes, the secured rules database 4100 shown in 
Figure 41 , allows a cruise operator to create CPO rules by specifying some or all of the 
following restrictions in fields 4112 through 4144: origin ports, cruise numbers 
(included or excluded), dates and times of departure, departure day of the week, dates 
and times of return, return day of the week, number of passengers traveling, length of 
haul, average yield per cabin, minimum price per ticket, inventory restrictions or cabin 
availability, and advance purchase requirements. 

For example, record 4102, shown in Figure 41, is associated with a CPO 
rule for a given cruise operator which specifies that the cruise operator will accept any 
CPO for travel from St. Thomas during the month of October, 1997, provided that (i) 
the customer travels on any cruise departing and returning on a Tuesday through 
Thursday, (ii) the tickets are booked within two (2) months of departure, (iii) the yield is 
at least $1.20 per mile per cabin and the price is at least $529 per person, (iv) is not for 
luxury class travel and (v) at least two (2) passengers are travelling together. 
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POST-SELL FOR MULTIPLE BINDS 
As discussed above, if a CPO is accepted by more than one airline or 
cruise operator, then a tie breaker algorithm is preferably executed by the CPO 
management process 3600 during step 3652 to determine which airiine acceptance to 
5 utilize. For example, the tie breaker algorithm can select a seller offering an itinerary 
which maximizes the convenience to the customer 2110, maximizes the profit to the 
CPO management system 2100, optimizes the inventory available for sale by the CPO 
management system 2100 or permits the customer 2110 to select for himself which 
airline or cruise operator acceptance to utilize. In an alternate implementation, if a CPO 
10 is accepted by more than one cruise operator, the CPO management system 2100 
executes a post-sell multi-bind process 4200, shown in Figure 42. to permit each 
accepting seller to directly market to the customer 2110 and post-sell their product. 
Thus, the customer 2110 still selects for himself which cruise operator acceptance to 
utilize, based on materials or incentives furnished by each seller. The customer 2! 10 is 
15 still bound by the CPO management system 2100, in accordance with the terms of the 
CPO. In other words, the customer 21 10 is obligated to purchase the goods or services 
specified by the CPO, but the buyer must decide which cruise operator to utilize, based 
on materials provided to the customer 2110 directly by each accepting cruise operator. 

For example, a customer 2110 may submit a CPO for a cruise during the 
20 month of March, 1998, anywhere in the Virgin Islands, in a grade A cabin with late 
dining, for $800.00. The CPO is provided to a plurality of cruise operators. Three 
cruise operators accept the CPO. The CPO management system 2100 then binds the 
customer 21 10 on the credit card account identified with the offer, in accordance with 
the restrictions of the CPO. The CPO management system 2100 then provides a 
25 channel of communication between the customer 2110 and the accepting sellers, or 
provides the customer contact information to each accepting cruise operator, who each 
attempt to market their product in an attractive manner. The customer 2110 then selects 
one of the three accepting sellers. Thus, each cruise operator knows that they have a 
one-in-three chance of selling a cruise, at the price specified by the CPO. It is 
30 anticipated that cruise operators would aggressively market to such guaranteed 
purchasers, particulariy in view of the high marginal profits associated with each cruise 
traveler. 
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It is noted that the channel of communication provided by the CPO 
management system 2100 between the customer 21 10 and each accepting seller may be 
an interactive web-site or other electronic mechanism that permits each accepting seller 
to present the customer 2110 with detailed information about the cruise they are 
5 attempting to market. For example, the interactive web-site might include virtual 
representations of different aspects of the cruise package, such as the actual cruise ship 
and cabins, as well as the various ports that the cruise will visit and the available 
activities. In this manner, the buyer can explore the virtual cruise representation using 
known technology. 

10 Figure 42 illusttates an illustrative post-sell multi-bind process 4200 

which may be implemented by the CPO management central server of Figure 22 to 
permit each accepting seller to directly market to the customer 21 10 in an attempt to 
post-sell their product. The post-sell multi-bind process 4200 is preferably executed by 
the CPO management process 3600 during step 3652, in lieu of the tie breaker 

15 algorithm, to determine which cruise operator acceptance to utilize. As illustrated in 
Figure 42, the post-sell multi-bind process 4200 begins during step 4210, by instructing 
the accepting cruise operators or other sellers to provide post-sell information for a 
designated customer 21 10. The CPO management system 2100 then preferably receives 
the post-sell information from the accepting operators during step 4220 and transmits, 

20 or otherwise makes available, the received information to the customer 2110 during step 
4230. Finally, the post-sell multi-bind process 4200 receives the decision of the 
customer 2110 regarding which operator to utilize, before program control returns to the 
CPO management process 3600 during step 4250. 

In an alternate implementation, if a CPO is accepted by more than one 

25 cruise operator, then the CPO management system 2100 can bind each of the accepting 
sellers to the one CPO. The original buyer can be assigned one of the sellers in 
accordance with the tie breaker algorithm or the alternative post-sell multi-bind process 
4200 disclosed herein. In this manner, the CPO management system 2100 can then 
resell the excess inventory to other buyers at or above the price associated with the 

30 initially accepted CPO. 
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EXCLUDED SELLER CPO EVALUATION 
As previously indicated, a CPO submitted by a customer 2110 can 
specify one or more preferred airline(s). cruise operators or other sellers, as applicable. 
Thus, the CPO management system 2100 will provide the CPO to each specified seller 
to determine if one or more of the sellers are willing lo accept the CPO. In a 
supplemental embodiment, the CPO management system 2100 preferably executes an 
excluded seller CPO evaluation process 4400. discussed below in conjunction with 
Figures 44a and 44b. to provide the CPO to the excluded sellers who may make 
counteroffers to the customer 21 10 before one of the specified sellers accepts the CPO. 
The excluded sellers may make counteroffers which are more favorable than the 
original terras of the CPO specified by the customer 2110, in an attempt to obtain the 
business. In this manner, the CPO management system 2100 can sell the rights to 
receive CPO information to excluded sellers or collect a larger percentage commission 
for any counteroffers which are accepted by a customer 21 10. 

For example, in the cruise industry, first time cruisers tend to develop a 
specific brand loyalty. Thus, when considering future cmises, such customers 2110 
may submit a CPO to a very limited number of cruise operators. The CPO management 
system 2100 would submit the CPO to the specified cruise operators, in accordance with 
the terms of the CPO. and also submit the CPO to one or more excluded cruise 
operators. The CPO management system 2100 preferably utilizes an excluded operator 
counteroffer database 4300. shown in Figure 43. to maintain any counteroffers received 
from the excluded operators, before the CPO is accepted by one of the customer- 
specified operators. 

An illustrative excluded operator counteroffer database 4300 for a cruise 
implemenution is shown in Figure 43. The excluded operator counteroffer database 
4300 maintains a plurality of records, such as records 4305 through 4315, each 
associated with a different counteroffer received from an excluded operator. For each 
counteroffer identified by number in field 4325. the excluded operator counteroffer 
database 4300 includes the corresponding CPO number, a customer identifier, the 
excluded operator, the terms of the counteroffer and the associated status in fields 4330 
through 4350. respectively. For example, if a customer's CPO iniually specified that 
the offer be submitted to Holland AmericaLine or Seaborn Cruise Lines, the CPO 
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management system 2100 might first submit the offer to Carnival, Princess and Royal 
Caribbean Cruise Lines. As shown in Figure 43, each of the excluded operators submit 
counteroffers of $600, $600 and $575, respectively. If none of the operators originally 
specified by the customer's CPO have not yet accepted, then the customer 2110 is 

5 provided the option of accepting one of the counteroffers. If the customer 2110 accepts 
a counteroffer, then the customer 21 10 is bound to the terms of the counteroffer, and the 
original CPO is cancelled. 

Figures 44a and 44b describe an illustrative excluded seller CPO 
evaluation process 4400. This process 4400 may be implemented by the CPO 

10 management central server of Figure 22 to provide the CPO information to the sellers 
excluded by the terms of the original offer. Those excluded sellers can then attempt to 
obtain the business, before one of the sellers specified by the terms of the CPO accepts 
the CPO. As discussed below, the excluded seller CPO evaluation process 4400 is 
preferably executed in conjunction with die CPO management process 3600. As 

15 illustrated in Figure 44a, the excluded seller CPO evaluation process 4400 begins during 
step 4405, upon receipt of a CPO from a customer 21 10 and storage of the CPO in the 
CPO database 2900 or 4000. Thereafter, the CPO is evaluated during step 4410 to 
retrieve any operators specified by the customer 2110. The operator database is 
accessed during step 4415 to identify potential operators to which the CPO information 

20 can be provided. 

A test is then performed during step 4420 to determine if there are one or 
more operators excluded from the terms of the CPO. If it is determined during step 
4420 that no operators arc excluded from the customer's CPO, then the CPO 
management process 3600 continues operation as described above. If. however, it is 

25 determined during step 4420 that one or more operators are excluded from the 
customer's CPO, then the CPO information is preferably transmitted to each specified 
and excluded operator during step 4430. It is noted that the CPO can be provided to 
excluded operators before specified operators, or concurrently. 

Any counteroffers are then received from the excluded operators during 

30 step 4435, and stored in the excluded operator counteroffer database 4300 during step 
4440. Each of the received counteroffers are then presented to the customer 2110 
during step 4445. A test is then performed during step 4450 to determine if the customer 



90 



M^O 98/10361 



PCTAJS97/15492 



2110 accepts any of the counteroffers before the original CPO is accepted by any of the 
specified operators. If it is determined during step 4450 that the customer 21 10 does not 
accept any of the counteroffers before the original CPO is accepted by any of the 
specified operators, then the CPO management process 3600 continues operation as 
described above. 

If, however, it is determined during step 4450 that the customer 2 1 10 has 
accepted a counteroffer before the original CPO is accepted by any of the specified 
operators, then the original CPO is terminated or cancelled and the status of the original 
CPO in the CPO database 2900, 4000 is changed to "cancelled" during step 4460. 
Thereafter, the status of the accepted counteroffer is changed to "accepted" and the 
status of the rejected counteroffers, if any, are changed to "rejected" in the excluded 
operator counteroffer database 4300 during step 4465. Finally, program control returns 
to the CPO management process 3600 and continues in the manner described above. 

Although the post-sell multi-bind process 4200 and the excluded seller 
CPO evaluation process 4400 have been illustrated herein in a cruise embodiment, it is 
noted that the post-sell multi-bind process 4200 and the excluded seller CPO evaluation 
process 4400 are applicable in other industries as well, including the airiine and other 
travel-related industries, the long distance telephone industry and the finance industry, 
as would be apparent to a person of ordinary skill. 

PACKAGE CPO MANAGEMENT SYSTEM 

A further embodiment of the present invention, suitable for processing 
the sale of packages of goods and services, is discussed below in conjunction with 
Figures 45 through 57. Figure 45 shows a conditional purchase offer (CPO) 
management system for receiving and processing CPOs from one or more buyers, 
utilizing buyer interfaces 4800, for packages of component goods or services. In one 
embodiment, the package CPO management system 4500 deconstructs or breaks up an 
overall package CPO into component CPOs which are individually offered to sellers. 
The package CPO management system 4500 processes the individual component CPOs 
associated with each package CPO to determine whether one or more sellers, utilizing 
seller interfaces 4801-4806. are willing to accept each of the individual components of a 
given package CPO. As discussed further below, if each of the individual component 
CPOs of a given package CPO are accepted by one or more sellers, the package CPO 
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management system 4500 binds the buyer, on behalf of each of the accepting sellers, to 
purchase the entire package. In this manner, a legally binding contract is formed. 

As used herein, a package CPO is a binding offer containing one or more 
conditions submitted by a buyer for the purchase of a package of component goods or 
services or both, such as air travel, hotel and car rental, at a buyer-defined price. In the 
illustrative travel embodiment, the buyer-defined conditions for a package CPO would 
generally include overall price and itinerary parameters, such as the origin and 
destination cities: acceptable dates and times of travel; and desired class of service for 
each individual component. In addition, a buyer may optionally provide more detailed 
specifications for one or more individual components of an overall package CPO. such 
as whether connecting flights or stopovers are acceptable to the buyer for the airline 
portion of a travel-related package CPO. or a preferred provider for one or more 
individual component goods or services. 

According to one feature of the present invention, the package CPO 
management system 4500 preferably deconstructs an overall package CPO into 
component CPOs which are individually offered to sellers. In an alternate embodiment, 
the package CPO management system 4500 provides the overall package CPO to each 
seller, with sellers being able to separately accept each component of the package CPO. 
It is noted that the individual components of a package CPO can be for identical 
products. For example, a buyer can submit a purchase offer for six (6) general 
admission tickets to a particular sporting event. The package CPO management system 
4500 can provide the purchase offer to sellers as an integral CPO for six tickets which 
may only be accepted by one seller. Alternatively, the package CPO management 
system 4500 can deconstruct the overall package CPO for six tickets into a number of 
component CPOs for one or more tickets which are individually offered to sellers. In 
one implementation, an overall package CPO for bulk goods can be deconstructed into 
component CPOs which arc optimized into units which are most likely to be accepted. 
In the above ticket example, the package CPO management system 4500 can 
decompose the request for six tickets into three component CPOs for two tickets each, 
assuming that most sellers are looking to sell pairs of tickets. 

In one preferred embodiment, the package CPO management system 
4500 reserves a margin off of the total offer price, before calculating the offer price for 
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each component CPO. The reserved margin amount may be determined based on the 
likelihood that all components of the overall package will be bound. In this manner, the 
margins mitigate the risk incurred by the package CPO management system 4500 as a 
result of a failure to bind all components of a package CPO. 

As discussed further below in conjunction with Figure 56. the package 
CPO management system 4500 can utilize the reserved margin or portions thert:of to 
increase the offer price of one or more component CPOs that remain unaccepted by 
sellers. For example, if a buyer were to submit an offer for a vacation package with a 
total cost not to exceed one thousand dollars ($1,000.00). the package CPO 
management system 4500 may retain a one hundred dollar margin ($100), or ten percent 
(10%). to uulize if components of the desired package cannot be bound with the offer 
prices allocated from the initial $900. If, however, the package CPO management 
system 4500 is successful in binding the entire package with the initially allocated $900. 
then the package CPO management system 4500 can retain the $100 margin as profit, 
renim the margin to the buyer, or place the unused margin in a fund to help bind the 
component CPOs of other package CPOs. 

In order to calculate an offer price for each component CPO, the package 
CPO management system 4500 preferably initially determines the total market price of 
the package based on the maricet price of each individual component good or service 
within the package. The package CPO management system 4500 then calculates an 
offer price for each component CPO based on the total price offered by the buyer for the 
entire package, as adjusted by the reserved margin, if appropriate, multiplied by the 
ratio of the maricet price of the respective component CPO to the total market price of 
the package. For example, if a buyer submits an offer for a travel package consisting of 
air travel, hotel accommodaUons and a car rental, widi a total cost for the package not to 
exceed one thousand dollars ($1,000.00). and with each component item having a 
maricet price of $420. $400 and $250. respectively, the package would have a total 
market price of $1070. If a $100 margin is initially retained by the package CPO 
management system 4500. the $900 adjusted package CPO price would be allocated to 
the individual component CPOs as follows based on the maricet prices: $360 (40%) for 
airiine tickets. $333 (37%) for hotel accommodaUons and $207 (23%) for car rental. 
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The package CPO management system 4500 then processes the 
individual component CPOs to determine whether one or more sellers are willing to 
accept each of the individual component CPOs of the overall package CPO. If 
successful, the package CPO management system 4500 binds the buyer, on behalf of 
5 each of the accepting sellers, to purchase the entire package. As discussed further 
below, as each individual component CPO is accepted by a seller, the package CPO 
management system 4500 preferably enters a "pre-bind" agreement with the seller, 
whereby the component good or service is reserved for a predefined time period to 
permit the package CPO management system 4500 to complete the processing of the 

10 remaining active component CPOs. A seller who accepts a component CPO may permit 
the package CPO management system 4500, for example, a two-week period within 
which the package CPO management system 4500 must complete the package. It is 
noted that such a limited predefined "pre-bind" period protects sellers from reserving a 
product that cannot be later sold. 

'5 In an alternate implementation, the package CPO management system 

4500 can enter binding agreements with each seller who elects to accept a component 
CPO. In this implementation, if parts of the package were bound, and others were not at 
the time of expiration, the package CPO management system 4500 could fund the 
difference to complete the unaccepted components of the package at or near market 

20 prices. In a further alternate implementation, the package CPO management system 
4500 can provide component CPOs to sellers in a particular serial order, based on the 
likelihood that each component of the package will bind. 

In addition, a seller can preferably be ensured that the package CPO 
management system 4500 could not continue shopping an accepted component CPO to 

25 the seller's competitors after a pre-bind is obtained by encrypting the initial pre-bind. 
For example, a seller who pre-binds a given component CPO can encrypt their 
identifying characteristics before transmitting their acceptance to the package CPO 
management system 100 so that the package CPO management system 4500 can 
identify the seller's industry, such as airline, and authorization to accept offers, but 

30 could not identify the seller's specific identity until the entire package was complete. 

Although the package CPO management system 4500 is illustrated 
herein as a system for processing uravel-related package CPOs, the package CPO 
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management system 4500 could be utilized to process packages of any component 
goods or services or both, such as automobiles and related insurance, computers and 
related peripheral equipment, or bulk goods, as would be apparent to a person of 
ordinary skill. 

5 PACKAGE CPO MANAGEMENT SYSTEM 

As shown in Figure 45, the package CPO management system 4500 
preferably includes a central controller 4600 and one or more secured servers 4700, for 
communicating with one or more buyer or seller interfaces 4800-4806. The package 
CPO management system 4500 may provide a given component CPO to selected sellers 

10 based on the industry associated with the component CPO or other predefined screening 
criteria, as shown in Figure 45, so that sellers only obtain component CPOs that they 
may be interested in or arc authorized to screen. Alternatively, the package CPO 
management system may provide all component CPOs to all sellers for screening. 

According to one feature of the present invention, the package CPO 

J5 management system 4500 preferably provides an optional agency feature that permits 
the package CPO management system 4500 to accept or reject a given component CPO 
on behalf of certain agency-based sellers who have delegated such authority to the 
package CPO management system 4500. Thus, the package CPO management system 
4500 preferably (i) evaluates component CPOs on behalf of certain agency-based sellers 

20 who have delegated authority to the package CPO management system 4500 to accept 
or reject a given component CPO, and (ii) permits broadcast-based sellers to evaluate 
component CPOs independently. Thus, the package CPO management system 4500 can 
preferably provide one or more component CPOs of a received package CPO to each 
broadcast-based seller, for the seller to independently determine whether or not to 

25 accept a given component CPO. It is noted that the package CPO management system 
4500 can provide a component CPO to each appropriate broadcast-based seller, for 
example, by means of a broadcast transmission, or by means of posting the component 
CPO, for example, on an electronic bulletin board accessible by each broadcast-based 
seller. Alternatively, the package CPO management system 4500 can evaluate one or 

30 more component CPOs of a received package CPO against a number of CPO rules 
defined by one or more agency-based sellers, to decide on behalf of an agency-based 
seller to accept or reject a given component CPO. Thus, the package CPO management 
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system 4500 can determine if one or more sellers accepts a given component CPO by 
providing the component CPO to each seller and receiving an acceptance or rejection, or 
by applying the component CPO to the CPO rules to render a decision to either accept, 
reject or counter a component CPO on behalf of a particular seller. 

As discussed further below, a CPO nilc is a set of restrictions defined by 
a given agency-based seller, such as seller 4804. to define a combination of such 
restrictions for which the seller is willing to accept a predefined minimum price. In one 
embodiment, the CPO rules are generated by the revenue management system, yield 
management system, or profit management system of the respective agency-based 
seller, or by any system that controls and manages inventory. For a more detailed 
discussion of CPO rules, the manner in which they are generated and related security 
issues, see U.S. Patent Application Serial No. 08/889.319. entitled Conditional Purcha.se 
Offer Management System, filed July 8. 1997, the parent application lo the present 
invention, which is incorporated by reference herein. Generally, the revenue 
15 management system, for example, will employ a CPO rules generation process to 
generate CPO rules by evaluating current inventory, pricing and revenue information, as 
well as historical patterns and external events, to forecast future travel. 

For example, a CPO rule for a given agency-based airiine can specify 
that the airline will accept any component CPO for travel between Newark, New Jersey 
20 (EWR) and Orlando, Florida (MCO) during the month of October, 1997, provided that 
(i) the customer travels between Tuesday and Thursday, (ii) the tickets are booked 
within 21 days of departure, (iii) the price is at least $165 per ticket, (iv) K-class 
inventory is available on all flight segments of the customer s itinerary, and (v) there are 
at least two (2) passengers travelling together. 
25 As discussed further below in conjunction with Figure 47, each secured 

server 4700 may be associated with one or more agency-based sellers and each server 
4700 stores, among other things, the CPO rules defined by any associated agency-based 
sellers, such as sellers 4804 and 4806. Each secured server 4700 may be remotely 
located from the central controller 4600. as shown in Figure 45, or may be integrated 
30 with the central controller 4600. In one remote embodiment, the secured server 4700 
associated with each agency-based seller may be physically located at a processing 
facility secured by the particular seller, or at the physical location of a third party. 
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As discussed further below, each buyer contacts the package CPO 
management system 4500, for example, by means of telephone, facsimile, online access, 
e-mail, in-person contact or through an agent, and provides the package CPO 
management system 4500 with the terms of their package CPO. It is noted that each 
buyer may employ a general-purpose computer, such as the buyer interface 4800, 
discussed below in conjunction with Figure 48. for communicating with the package 
CPO management system 4500. The general-purpose computer of each buyer is 
preferably comprised of a processing unit, a modem, memory means and any software 
required to communicate with the package CPO management system 4500. 

Once the terms of the package CPO have been received by the package 
CPO management system 4500, the central controller 4600 will execute a package CPO 
posting process 5500. discussed below in conjunction with Figures 55a through 55c. to 
deconstruct the overall package CPO into component CPOs, and thereafter (i) provide 
each component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
component CPO against the appropriate CPO mies of each appropriate agcncy-ba.sed 
seller. In addiUon, once the component CPOs have been posted, the package CPO 
management system 4500 will preferably periodically execute a package CPO 
monitoring process 5600, discussed further below in conjunction with Figures 56a 
through 56c, to determine if each component CPO of an overall package CPO is 
accepted by an appropriate seller. If each of the individual component CPOs of a given 
package CPO are accepted by one or more sellers, the package CPO management 
system 4500 notifies the buyer, on behalf of each of the accepting sellers, that he has 
been bound to purchase the entire package with the appropriate restrictions which meet 
the conditions defined by the buyer. 

The package CPO management system 4500 and buyer and seller 
interfaces 480^4806 (collectively, the "nodes") preferably transmit digitally encoded 
data and other information between one another. The communication links between the 
nodes preferably comprise a cable, fiber or wireless link on which electronic signals can 
propagate. For example, each node may be connected via an Internet connection using 
a public switched telephone network (PSTN), such as those provided by a local or 
regional telephone operating company. Alternatively, each node may be connected by 
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dedicated data lines, cellular. Personal Communication Systems ("PCS"), microwave, or 
satellite networks. 

Figure 46 is a block diagram showing the architecture of an illustrative 
central controller 4600, The central controller 4600 preferably includes certain standard 
5 hardware components, such as a central processing unit (CPU) 4605, a random access 
memory (RAM) 4610, a read only memory (ROM) 4620, a clock 4625, a data storage 
device 4630, an operating system 4650, a payment processor 4660 and a network 
interface 4680. The CPU 4605 is preferably linked to each of the other listed elements, 
cither by means of a shared data bus, or dedicated connections, as shown in Figure 46. 

10 The CPU 4605 may be embodied as a single commercially available 

processor, such as Intel's Pentium 100 MHz P54C microprocessor. Motorola's 120 MHz 
PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-1 
microprocessor. Alternatively, the CPU 4605 may be embodied as a number of such 
processors operating in parallel. 

>5 The ROM 4620 and/or data storage device 4630 are operable to store one 

or more instructions, discussed further below in conjunction with Figures 55 and 56, 
which the CPU 4605 is operable to retrieve, interpret and execute. The payment 
processor 4660 preferably implements known processes to accomplish the transfer of 
required payments, charges and debits, between the sellers and buyers, by means of a 

20 conventional electronic funds transfer (EFT) network. In particular, as discussed below 
in conjunction with Figure 56, the package CPO monitoring process 5600 preferably 
transmits the credit card information associated with a given buyer to the credit card 
issuer for payment, if a package is actually purchased by the buyer. The processing of 
such accounting transactions are preferably secured in a conventional manner, for 

25 example, using well-known cryptographic techniques. 

The CPU 4605 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 4630 or ROM 4620. The ALU is 

30 operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 
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As discussed further below in conjunction with Figures 49 through 53 
respectively, the data storage device 4630 includes a buyer database 4900 a seller 
database 5000. a package CPO database 5100. a component CPO database 5200 and a 
market price database 5300. The buyer database 4900 preferably stores information on 
each buyer of the package CPO management system 4500. including biographical 
mformation and billing information, such as a credit card number. The seller database 
5000 preferably stores information on each seller which is registered with the package 
CPO management system 4500 to sell component goods or services to package CPO 
buyers, including identifier and name information. The package CPO database 5100 
preferably contains a record of each package CPO being processed by the package CPO 
management system 4500, including an indication of the component CPOs within each 
package CPO and the as.sociated status. The component CPO database 5200 preferably 
contains a record of each component CPO being processed by the package CPO 
management system 4500. including the terms of each component CPO and the 
associated status. Finally, the market price database 5300 preferably stores market price 
mformation for each component good or service processed by the package CPO 
management system 4500. 

In addition, the data storage device 4630 includes a package CPO posting 
process 5500 and a package CPO monitoring process 5600. discussed further below in 
conjunction with Figures 55 and 56. respectively. Generally, the package CPO posting 
process 5500 deconstructs the package CPO into componem goods or services and 
thereafter (i) posts each component CPO to the appropriate broadcast-based sellers and 
0.) evaluates each component CPO against the appropriate CPO niles of each agency- 
based seller. The package CPO monitoring process 5600 determines if each component 
CPO of a posted package CPO is accepted by an appropriate seller and, if accepted 
provides buyer information to each accepting seller. In this manner, if each of the 
mdividual component CPOs of a given package CPO are accepted, the package CPO 
management system 4500 notifies the buyer, on behalf of each of the accepting sellers, 
that he has been bound to purchase the entire package. 

The networic interface 4680 connects the central controller 4600 to the 
buyer and sellers, for example, by means of an Internet connection using the public 
switched telephone network (PSTN). The network interface 4680 preferably includes 
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multiple communication channels for simultaneously establishing a plurality or 
connections. 

Figure 47 is a block diagram showing the architecture of an illustrative 
secured server 4700. As previously indicated, the package CPO management system 

5 4500 may utilize one or more secured servers 4700, each supporting one or more 
agency-based sellers 4804, 4806. Each secured server 4700 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 4705, a random 
access memory (RAM) 4710, a read only memory (ROM) 4720, a clock 4725, a data 
storage device 4730, and a communications port 4740. Each of these components may 

10 be identical to those described above in conjunction with Figure 46. 

As previously indicated, in one embodiment, the CPO mics may be 
stored in a secure database to maintain the integrity and confidentiality of the highly 
sensitive information included in each CPO rule. Thus, the secured server 47(K) 
preferably uses a secure database, such as the products commercially available from 

15 Oracle, Informix or IBM. 

As discussed further below in conjunction with Figure 54, the data 
storage device 4730 includes a secured seller rules database 5400. The secured seller 
rules database 5400 preferably maintains the CPO rules for the one or more agency- 
based sellers associated with the secured server 4700. As previously indicated, the 

20 secured seller rules database 5400 may be stored in an encrypted format to maintain the 
integrity and confidentiality of the highly sensitive information included in the CPO 
rules. In addition, the data storage device 4730 includes a component CPO rule 
evaluation process 57(X), discussed further below in conjunction with Figure 57. 
Generally, the component CPO rule evaluation process 57(K) is a subroutine executed by 

25 the package CPO posting process 5500, which receives a component CPO and 
compares the CPO against the rules of one or more agency-based sellers to generate a 
response on behalf of the sellers to the given component CPO. 

The secured server 4700 may optionally maintain an audit trail for each 
component CPO that is processed by the package CPO management system 4500. For a 

30 discussion of a suitable audit system, see the parent application to the present invention, 
incorporated by reference herein above. 
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The communications port 4740 connects the secured server 4700 to the 
central controller 4600. The communications port 4740 preferably includes multiple 
communication channels for simultaneously establishing a plurality of connections. 

Figure 48 is a block diagram showing the architecture of an illustrative 
buyer or seller interface 4800-4806. The interface 4800 preferably includes certain 
standard hardware components, such as a central processing unit (CPU) 4808. a random 
access memory (RAM) 4810, a read only memory (ROM) 4820. a clock 4825, a data 
storage device 4830, and a communications port 4840. Each of these components may 
be identical to those described above in conjunction with Figure 46. In addition, the 
interface 4800 preferably includes a video monitor 4850 and related video driver 4860, 
and an input device 4870. such as a keyboard or mouse. 

The data storage device 4830 preferably includes a message database 
4880 for storing messages required by the respective buyer or seller interface 4800-4806 
to communicate with the central controller 4600 of the package CPO management 
system 4500. The communications port 4840 connects the interface 4800 to the central 
controller 4600 or the secured server 4700. for broadcast-based and agency-based 
sellers, respectively. 

Figure 49 illustrates an exemplary buyer database 4900 that preferably 
stores infonnaion on each buyer of the package CPO management system 4500 
including biographical information and billing information, such as a credit card 
number. The buyer database 4900 maintains a plurality of records, such as records 
4905-4915, each associated with a different buyer. For each buyer identifier in field 
4920, the buyer database 4900 includes the corresponding buyer name and address in 
fields 4925 and 4930, respectively, and credit card number in field 4935. In addition 
the buyer database 4900 preferably includes an indication of the CPOs associated with 
the buyer in field 4940. which may be package CPOs as described herein or general 
CPOs as described in the parent application to the presem invention. The identifier 
stored in field 4920 may be utilized, for example, to index a historical database (not 
shown) of previous purchases and CPOs associated with the buyer. 

Figure 50 illustrates an exemplary seller database 5000 which preferably 
stores information on each seller which is registered with the package CPO management 
system 4500 to sell component goods or services to package CPO buyers, including 
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identifier and name information. The seller database 5000 maintains a plurality of 
records, such as records 5005-5030, each associated with a different seller. For each 
seller identifier listed in field 5035, the seller database 5000 includes the corresponding 
seller name in field 5040. In addition, the seller database 5000 preferably records a 

5 tracking number in field 5045 for any CPOs associated with each seller. It is noted that 
the information recorded in field 5045 could be similarly recorded by including a seller 
ID field in the package CPO database 5100, discussed below. 

Figure 51 illustrates a package CPO database 5100 which preferably 
contains a record of each package CPO being processed by the package CPO 

10 management system 4500, including an indication of the component CPOs within each 
package CPO and the associated status. The package CPO database 5100 maintains a 
plurality of records, such as records 5105-5110, each associated with a different 
package CPO. For each package CPO listed in field 5120, the package CPO database 
5100 includes the status and original offer price in fields 5125 and 5130, respectively. 

15 In addition, the package CPO database 5100 preferably records the margin factor, 
remaining margin, adjusted package CPO price and per-allocation-margin percentage in 
fields 5135 through 5150, respectively. The manner in which the margin variables are 
processed by die package CPO management system 4500 are discussed below in 
conjunction with Figure 56. The posting and expiration dates of the package CPO, as 

20 well as the total posting duration period and posting time required for each margin 
allocation are stored in fields 5155 through 5170, respectively. The individual 
component goods or services within each package CPO are optionally identified in field 
5175, and the conditions and component numbers associated with each component are 
set forth in fields 5 1 80 and 5 185. It is noted that the information recorded in fields 5 175 

25 and 5180 could alternatively be retrieved from the component CPO database 5200 using 
the component CPO numbers recorded in field 5185. Finally, an identifier of the buyer 
associated with each package CPO is preferably recorded in field 5190. 

Figure 52 illustrates an exemplary component CPO database 5200 which 
preferably contains a record for each component CPO being processed by the package 

30 CPO management system 4500, including the terms of the component CPO and the 
associated status. The component CPO database 5200 maintains a plurality of records, 
such as records 5205 through 5230, each associated with a different component CPO 
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being processed by the system 4500. For each component CPO identified by 
component CPO number in field 5240. the component CPO database 5200 includes the 
status or expiration date for pre-bound component CPOs in field 5245 as well as the 
corresponding subject, price and conditions associated with the component CPO in 
5 fields 5250 through 5260. respectively. Finally, an identifier of the buyer associated 
with each component CPO is preferably recorded in field 5265. 

Figure 53 illustrates an exemplary market price databa.se 5300 that 
preferably stores market price information for each component good or service 
processed by the package CPO management system 4500. As discussed funher below 
0 m conjunction with Figure 55. the package CPO posting process 4500 preferably 
ufhzes the market price information to allocate the overall package price to each 
component good or .service. The market pnce database 5300 maintains a plurality of 
records, such as records 5305 through 5345. each associated with a different component 
good or service processed by the system 4500. For each component good or service 
Identified in field 5360. the market price database 5300 identifies the available quality 
or service levels for each good or service in field 5365. as well as the conesponding 
market price set forth in field 5375. for each time period indicated in field 5370 It is 
noted that the market price for each service level of round trip airline travel is preferably 
recorded for each originating and destination city pair (O & D Pair). 

As previously indicated, the secured server 4700 preferably maintains 
one or more secured seller rules databases 5400 to store the CPO rules for the one or 
more agency-based seller, associated with the secured server 4700. An example of a 
secured seller mles database 5400 is shown in Figure 54a for an agency -based airline 
and in Figure 54b for an agency -based hotel. 

Figure 54a illustrates an exemplary secured airline rules database 5400 
which preferably maintains the CPO rules for one or more agency-based airlines 
associated with a particular secured sender 4700. As previously indicated, the secured 
airline mles database 5400 may be stored in an encrypted format to maintain the 
mtegnty and confidentiality of the highly sensitive information included in the CPO 
rules. n,e secured airline mles database 5400 maintains a plurality of records, such as 
records 5402 and 5404. each associated with a different CPO rule. For each CPO rule 
Identified by rule number in field 5410. the secured airline rules database 5400 includes 
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the associated restrictions defined by the respective agency-based airline in fields 5412 
through 5444. 

Figure 54b illustrates an exemplary secured hotel rules database 5450 
which preferably maintains the CPO rules for one or more agency-based hotels 

5 associated with a particular secured server 4700. As previously indicated, the secured 
hotel rules database 5450 may be stored in an encrypted format to maintain the integrity 
and confidentiality of the highly sensitive information included in the CPO rules. The 
secured hotel rules database 5450 maintains a plurality of records, such as records 5452 
through 5456, each associated with a different CPO rule. For each CPO rule identified 

10 by rule number in field 5460. the secured hotel rules database 5450 identifies the 
applicable hotel sites in field 5465 and includes the associated restrictions defined by 
the respective agency-based hotel in fields 5470 through 5490. 

As discussed above, the central controller 4600 preferably executes a 
package CPO posting process 5500, shown in Figures 55a through 55c, to deconstruct 

15 the package CPO into component goods or services, and thereafter (i) post each 
component CPO to the appropriate broadcast-based sellers and (ii) evaluate each 
component CPO against the appropriate CPO rules of each agency-based seller. As 
illustrated in Figure 55a, the package CPO posting process 5500 begins the processes 
embodying the principles of the present invention during step 5505, when a buyer 

20 submits a CPO for a package of component goods or services. 

Thereafter, the central controller 4600 will receive the conditions 
associated with the package CPO from the buyer, including a description of each 
component good or service, and an identifier of a general purpose account, such as a 
credit or debit card account from which funds may be paid during step 5510, and then 

25 receive the price and expiration date for the package CPO from the buyer during step 
55 15. In this manner, the offer is guaranteed with a general purpose account, for 
example, using a line of credit on a credit card account. Appropriate legal language is 
preferably displayed or read to the buyer during step 5520 to form a binding package 
CPO. A package CPO number is generated during step 5525, and the package CPO 

30 information, including the buyer identifier, package CPO price and expiration date, and 
conditions for the component goods or services, is then entered into the package CPO 
database 5 100 during step 5530. 
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As previously indicated, the package CPO management system 4500 
preferably reserves a margin off of the total package offer price, before calculating the 
offer price for each component CPO. Thus, an appropriate margin is calculated during 
step 5535 by multiplying the package CPO price by the margin factor recorded in the 
package CPO database 5100. Thereafter, the calculated margin is recorded in the 
"remaining margin" field 5140 of the package CPO database 5100 during step 5540 
(Figure 55b). The adjusted CPO price is then calculated by subtracting the calculated 
margin from the original total package offer price, which is then entered into the 
package CPO database 5100 during step 5545. The status of the package CPO is set to 
"active" in field 5125 of the package CPO database 5100 during step 5550. 

The market price of each component good or service in the package CPO 
is retrieved during step 5555 from the market price database 5300. The market price of 
the overall package CPO is calculated during step 5560 by adding the market price of 
each individual component CPO in the overall package. The individual CPO prices for 
each component CPO are then calculated during step 5565, for example, by allocating 
the adjusted package CPO price, as calculated during step 5545, in accordance with the 
ratio of the market price of the respective component good or service to the total market 
price. 

A CPO number is then generated for each component CPO during step 
5570 and recorded in the "component CPO numbers" field of the package CPO database 
5100 during step 5575 {Figure 55c). A new record is created in the component CPO 
database 5200 for each component CPO during step 5580. before each component CPO 
is provided to each broadcast-based seller and the component CPO rule evaluation 
process 5700 is executed for each agency-based seller during step 5590. Program 
control terminates during step 5595. 

As discussed above, the central controller 4600 preferably executes a 
package CPO monitoring process 5600. shown in Figures 56a through 56c. to determine 
if each component CPO of a posted package CPO has been accepted by an appropriate 
seller and, if accepted, provides buyer information to each accepting seller. In this 
manner, if each of the individual component CPOs of a given package CPO are 
accepted, the package CPO management system 4500 notifies and binds the buyer, on 
behalf of each of the accepting sellers, to purchase the entire package. The package 
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CPO monitoring process 5600 may be periodically executed to determine the status of 
each component CPO, or executed continuously. 

As illustrated in Figure 56a, the package CPO monitoring process 5600 
begins the processes embodying the principles of the present invention during step 
5 5605, by performing a test to determine if all of the component CPOs within a given 
package CPO have been pre-bound at currently posted prices. It is noted that in the 
illustrative embodiment, the first seller to accept a given component CPO is awarded the 
component CPO. For a discussion of other mechanisms for determining which seller 
among a plurality of accepting sellers should be awarded a component CPO, .see the 

10 parent application to the present invention, incorporated by reference herein above. If it 
is determined during step 5605 that all of the component CPOs within a given package 
CPO have been pre-bound at currently posted prices, then buyer identification 
information, including the buyer's name, address and credit caid account number, is 
retrieved from the buyer database 4900 during step 5650. Thereafter, the buyer 

15 identification number is transmitted to each seller who accepted a component CPO 
during step 5655. The package CPO monitoring process 5600 transmits the merchant 
identifier of the package CPO management system 4500, together with the buyer's 
credit card account number, a billing descriptor and the purchase amount for the 
package CPO to the credit card issuer for payment authorization during step 5660. via a 

20 conventional credit card authorization network. 

The status field 5125 of the package CPO database 5100 is updated 
during step 5665 to indicate that the respective package CPO was completed, before 
program control terminates during step 5670. 

If, however, it was determined during step 5605 that all of the component 

25 CPOs within a given package CPO have not. been pre-bound at currently posted prices, 
then the expiration date of the package CPO is retrieved from field 5 1 60 of the package 
CPO database 5 100 during step 5610 (Figure 56b). A test is then performed during step 
5615 to determine if the package CPO has expired. If it is determined during step 5615 
that the package CPO has expired, without each component being pre-bound, then the 

30 package CPO monitoring process 5600 communicates ( I ) termination of any prc-bind 
agreements for component CPOs within the expired package CPO which were accepted 
by one or more sellers to the respective sellers during step 5635; and (1 1) expiration of 
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the package CPO to the respective buyer during step 5640. In an alternate embodiment, 
the buyer can be invited to resubmit a revised package CPO if the original package CPO 
is not accepted. In addition, the package CPO management system 4500 might attempt 
to compile a counteroffer for the buyer, based on acceptances of individual components 
5 received by the package CPO management system 4500. Thereafter, program control 
terminates during step 5645. 

If, however, it is determined during step 5615 that the package CPO has 
not expired, then the package CPO monitoring process 5600 will adjust the status field 
5125 of the package CPO database 5100 during step 5620 to indicate the percentage of 

10 the overall package CPO which is currently pre-bound. for example, by accessing the 
package CPO database 5100 to identify the number of components in the package CPO, 
and identifying the number of components which are currently pre-bound. Thereafter, 
the "total posting duration" parameter is retrieved from field 5165 of the package CPO 
database 5100 during step 5625, which is then multiplied by the "posting time required 

15 for each margin allocation" parameter set forth in field 51 70. 

A test is then performed during step 5630 to determine if the package 
CPO has been active for the posting lime required to allocate additional margin to 
increase the price of each component CPO which has not yet been pre-bound. If it is 
determined during step 5630 that the package CPO has not been active for the posting 

20 time required to allocate additional margin, then program control returns to step 5605 
(Figure 56a) and continues processing in the manner described above. If, however, it is 
determined during step 5630 that the package CPO has been active for the posting time 
required to allocate additional margin, then the percent composition of each remaining 
active component CPO is calculated during step 5675 (Figure 56c) relative to the total 

25 price of all remaining active component CPOs. 

The "per allocation margin percentage" is then retrieved during step 5680 
from field 5150 of the package CPO database 5100. The amount of margin to be 
allocated to remaining active component CPOs is then calculated during step 5682 by 
multiplying the retrieved "per allocation margin percentage" value by "remaining 

30 margin" value recorded in field 5140 of the package CPO database 5100. Thereafter, 
the allocable margin is applied to each remaining active component CPO in appropriate 
percentages during step 5684 by multiplying the price percentages of the remaining 
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active component CPOs (as determined during step 5675) by the calculated allocable 
margin amount. 

For example, if one component of a three component package is initially 
pre-bound at the originally posted price, and the remaining two components are not 
bound within the posting time required to allocate additional margin, then the package 
CPO monitoring process 5600 preferably allocates part of the margin between the two 
remaining component CPOs. The amount allocated to each component CPO is 
preferably determined by their respective initially posted prices. Assume in the 
example discussed above, where a buyer submits an offer for a travel package 
consisting of air travel, hotel accommodations and a car rental, with a total cost for the 
package not to exceed one thousand dollars ($1,000.00). that the first component to 
prebind was the airline tickets at $360. Thus, the package CPO monitoring process 
5600 will allocate a portion of the remaining margin to the offer prices for the hotel and 
car rental component CPOs. In a preferred embodiment, since the hotel component 
CPO accounts for 62% of the total remaining CPO prices ($333/($333 + $207)). the 
offer price of the hotel component CPO is increased by 62%, or $3 1 , of the money taken 
from the margin ($50). Likewise, the car rental component CPO offer price would be 
increased by 38% or $19. If one or more components are again not bound for the 
posting time required to allocate additional margin, more of the margin is preferably 
20 allocated. 

The "remaining margin" recorded in field 5140 is adjusted during step 
5688 by subtracting the margin allocated in the previous step. Thereafter, during step 
5690, the remaining active CPOs with the newly adjusted prices are provided to 
broadcast-based sellers and the component CPO rule evaluation process 5700 is 

25 executed for each appropriate agency-based seller. Finally, program control returns to 
step 5605 (Figure 56a) and continues processing in the manner described above, until all 
component CPOs are pre-bound. or until the package CPO expires. In this manner, the 
offer prices are increased with additional allocated margin for each component CPO that 
remains unaccepted for each time period required to allocate additional margin. As 

30 discussed above, the package CPO posting process 5500 and the package CPO 
monitoring process 5600 each execute a component CPO rule evaluation process 
during steps 5590 and 5690. respectively, for agency-based sellers to compare the 
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component CPOs against the rules of one or more ageticy-based sellers to generate a 
response on behalf of the sellers to the given component CPO. An illustrative 
component CPO rule evaluation process 4700 is shown in Figure 57. In one 
embodiment, the component CPO rule evaluation process 5700 is customized for each 
agency-based seller, so that each evaluation process 5700 receives the component CPO 
record from the central controller 4600 in a standard format for comparison against the 
rules of the associated seller, and returns a standard response of the seller to the 
component CPO, such as "accept" or "reject." 

As shown in Figure 57, the component CPO rule evaluation process 5700 
initially identifies all CPO rules in the secured seller rules database 5000 which are 
pertinent to the component CPO during step 5710. Thereafter, during step 5720, the 
buyer defined conditions from the component CPO record in the component CPO 
database 5200 arc then compared to the corresponding seller defined restrictions from 
the secured seller rules database 5000 during step 5720, for each CPO rule identified 
during the previous step. 

Thereafter, a test is performed during step 5730 to determine if the 
component CPO satisfies a CPO rule. If it is determined during step 5730 that the 
component CPO does not satisfy one CPO rule, then program control terminates during 
step 5770. If, however, it is determined during step 5730 that the component CPO does 
satisfy a CPO rule, then the component CPO number is retrieved from the component 
CPO database 5200 during step 5740, and then entered into the "CPO tracking number- 
field 5045 of die seller database 5000. The status of the component CPO in field 5245 
of the component CPO database 5200 is updated to "pre-bind completed" during step 
5760. before program control terminates during step 5770. In addition, a pre-bind 
expiration date can be added to field 5245. if mandated by the seller. 

CPO MANAGEMENT SYSTEM FOR TELEPHONE CALLS 
A fiirther embodiment of the present invention, suitable for processing 
purchase offers for one or more telephone calls, is discussed below in conjunction with 
Figures 58 through 66. Figures 58A and 58B show a conditional purchase offer (CPO) 
management system 5800 for receiving and processing CPOs for telephone calls from 
one or more calling parties, such as calling party 5810. The CPO management system 
5800 processes the CPO to determine whether one or more long distance carriers, such 
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as inlerexchange carriers 5820-5824, are willing lo accept a given CPO and complete a 
telephone call in accordance with restrictions defined by the calling party 5810. In the 
United States, for example, the interexchange carriers 5820-5824 may be AT&T, Sprint 
and MCI. As discussed further below, if an interexchange carrier 5820 accepts a given 

5 CPO, the CPO management system 5800 binds the calling party 5810 on behalf of the 
accepting interexchange carrier 5820, to form a legally binding contract. 

As used herein, a CPO is a binding offer containing one or more 
conditions, submitted by a calling party 5810 for the completion of one or m<irc 
telephone calls, typically at a price defined by the calling party. In this manner,- a 

10 calling party 5810 can preferably submit a CPO for an individual telephone call, a 
package of calls to one or more called parties 5830, or for a contract to provide 
telephone service for a predefined period of time. In the illustrative embodiment, the 
conditions defined by the calling party 5810 may include the telephone number to be 
called, the maximum price, one or more preferred carriers, if any, as well as any time 

15 limitations, such as a particular time-of-day or minimum call duration. The maximum 
price may preferably be specified by the calling party 5810 in terms of a price for a 
fixed period of time, such as ten dollars ($10) for a twenty (20) minute telephone call, or 
in terms of a rate-per-minute, such as fourteen cents per minute ($0.14/minute), 

CPO MANAGEMENT SYSTEM 

20 Figure 58A shows an illustrative network environment for 

interconnecting the CPO management system 5800 with one or more calling parties 
5810 and one or more interexchange carriers 5820-5824 who may route a call to a 
desired called party 5830. According to a feature of the present invention, a calling 
party 5810, desiring to call a called party 5830, typically identified by a Plain Old 

25 Telephone Service (POTS) telephone number, may submit an offer to the CPO 
management system 5800 for a telephone call in accordance with restrictions defined by 
the calling party. In one preferred implementation, the calling party 5810 uses a 
telephone set 5900, shown in Figure 59, to dial the telephone number assigned to the 
CPO management system 5800, such as a toll-free telephone number, or "800 number," 

30 before dialing the telephone number of the called party 5830 to provide the CPO 
management system 5800 with the terms of the CPO. Alternatively, the calling party 
5810 can initially contact the CPO management system 5800 by means of facsimile. 
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Once the calling party 5810 initially contacts the CPO management system 5800. the 
calling party 5810 then submits the terms of the CPO to the CPO management system 
5800. such as the maximum price for the call and the telephone number of the called 
party 5830. 

In a further variation, shown in Figure 58B, the calling party 5810 can 
initially contact the CPO management system 5800 by means of online access or e-mail 
using a subscriber terminal 5815, such as a gcneral-puipose computer, to access the 
Internet 5870. This online embodiment is particularly suited for a calling party 5810 
desiring to submit a CPO for a package of calls to one or more called parties 5830. or 
for a contract to provide telephone service for a predefined period of time. 

The tenns of the CPO may optionally be displayed to the calling party 
5810 on the telephone set 5900, as shown in Figure 59. In addition, the telephone set 
5900 can be specially configured with software for transmitting a CPO to the CPO 
management system 5800 or directly to the interexchange carriers 5820. For example, a 
speed dial button of die telephone set 5900 can be programmed to automatically 
transmit the terms of a CPO to the CPO management system 5800 or directly to the 
interexchange carriers 5820. In this manner, the calling party 5810 would program the 
terms of a given CPO using the keypad and function keys on the telephone set 5900, 
and then initiate transmission of the CPO using the speed dial button. 

As shown in Figure 58A, when the calling party 5810 dials the telephone 
number assigned to the CPO management system 5800. a connection is typically first 
established to a local switch operator 5850, which is the telephone switching system, for 
example, of the local telephone company. The local switch operator 5850 in turn 
connects the calling party to the Public Switched Telephone Network (PSTN). The local 
switch operator 5850 is capable of establishing a connection between the calling party 
5810 and one of a number of interexchange carriers 5820-5824 over a communications 
link 5860. in a manner well-known in the telephony art. The interexchange carriers 
5820 may be. for example, providers of long distance carrier networics, including circuit 
and packet switched networks or combinations thereof, and the communications link 
5860 may be a cable, fiber or wireless link on which electronic signals can propagate. It 
is noted that with the increasing trend for long distance carriers to provide local 
telephone service in many areas, and vice versa, the distinction between the local switch 
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operator 5850 and the interexchange carriers 5820-5824 may become transparent. One 
or more of the interexchange carriers 5820 may be able to route a call between a given 
calling party 5810 and a desired called party 5830. For a more detailed discussion of 
the manner in which a connection is made between a given calling party 5810 and a 
5 desired called party 5830, over a long distance carrier network by an interexchange 
carrier 5820, see U.S. Patent Number 4,191,860» incorporated by reference herein. 

According to a feature of the present invention, the CPO management 
system 5800 preferably provides an optional agency feature that permits the CPO 
management system 5800 to accept or reject a given CPO on behalf of certain agency- 

10 based interexchange carriers 5820 who have delegated such authority to the CPO 
management system 5800. Thus, the CPO management system 5800 preferably (i) 
evaluates CPOs on behalf of certain agency-based interexchange carriers 5820 who 
have delegated authority for deciding to accept or reject a given CPO to the CPO 
management system 5800; and (ii) permits broadcast-based interexchange carriers 5820 

15 to evaluate CPOs independently. Thus, the CPO management system 5800 can provide 
a CPO to each broadcast-based interexchange carrier 5820, for the interexchange carrier 
5820 to independently determine whether or not to accept a given CPO. It is noted that 
the CPO management system 5800 can provide a CPO to each broadcast-based 
interexchange carrier 5820, for example, by means of a broadcast transmission, or by 

20 means of posting the CPO, for example, on an electronic bulletin board accessible by 
each broadcast-based interexchange carrier 5820, 

In addition, the CPO management system 58(K) can evaluate a CPO 
against a number of CPO rules defined by one or more agency-based interexchange 
carriers 5820, to decide on behalf of an agency-based interexchange carrier 5820 to 

25 accept or reject a given CPO. Thus, the CPO management system 5800 can determine if 
one or more carriers accepts a given CPO by providing the CPO to each carrier and 
receiving an acceptance or rejection, or by applying the CPO to the CPO rules to render 
a decision to either accept, reject or counter a CPO on behalf of a particular carrier. 

As discussed further below, a CPO rule is a set of restrictions defined by 

30 a given agency-based interexchange carrier 5820, to define a combination of such 
restrictions for which the interexchange carrier 5820 is willing to accept a commitment 
to complete one or more telephone calls. In a preferred embodiment, the CPO rules are 
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generated by some type of revenue management system, yield management system, or 
profit management system of the respective agency-based interexchange carrier 5820. 
or by any system that controls and manages network capacity. For a more detailed 
discussion of CPO rules, the manner in which they are generated and related security 
issues, see U.S. Patent Application Serial No. 08/889,3 19. entitled Conditional Purchase 
Offer Management System, filed July 8. 1997, the parent application to the present 
invention, which is incorporated by reference herein. Generally, the revenue 
management system, for example, will employ a CPO rules generation process to 
generate CPO rules by evaluating current network capacity, pricing and revenue 
information, as well as historical patterns and external events, to forecast future calling 
demand. 

Once the terms of a CPO have been received by the CPO management 
system 5800. a central server 6000. discussed below in conjunction with Figure .60, will 
execute a CPO management process 6500, discussed below in conjunction with Figures 
65a and 65b. to (i) provide each CPO to the interexchange carriers 5820 and (ii) to 
determine if the terms of the offer have been accepted by any interexchange carrier 
5820. Thereafter, the CPO management system 5800 or the accepting interexchange 
carrier 5820 notifies the calling party 5810 of the response of the interexchange carriers 
5820 and. if accepted, the calling party 5810 is bound to complete and pay for one or 
more calls having the appropriate restrictions which meet the conditions defined by the 
calling party 5810. 

The CPO management system 5800 may optionally maintain an audit 
trail for each CPO that is processed by the CPO management system 5800. For a 
discussion of a suitable audit system, see the parent application to the present invention, 
incorporated by reference herein above. 

AcconUng to a ftirther feature of the invention, the CPO management 
system 5800 prevents calling parties 5810 from identifying the carrier's minimum price 
for the one or more telephone calls associated with a given CPO. For example, the CPO 
management system 5800 preferably does not disclose the carrier's minimum price to 
calling parties and optionally limits the number of CPOs that any calling party 5810 can 
submit within a predefined time period. In addition, the binding nature of the present 
invention discourages calling parties 5810 from submitting CPOs merely to identify the 
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minimum price, since the calling party 5810 will be obligated to complete one or more 
telephone call(s) in accordance with the terms of the CPO. In alternate embodiments, 
the calling party 5810 can be charged a fee or a penalty if a call is not completed when 
at least one carrier 5820 has accepted the CPO, or the CPO management system 5800 

5 can evaluate a rating of the calling party 5810 containing information regarding the 
likelihood that the calling party 5810 will complete one or more telephone calls 
corresponding to said CPO. For a more detailed description of a suitable rating system, 
see U.S. Patent Application Serial No. 08/811,349, filed March 4, 1997, entitled 
AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the 

10 present invention and incorporated by reference herein. In one embodiment, the 
evaluated rating comprises a ratio of completed calls to purchase offers by the customer 
5810. In this manner, the carriers 5820 can be confident that if the carrier accepts the 
calling party's offer, the calling party 5810 will complete the call(s) without using the 
information to ascertain the carrier's underlying level of price flexibility. 

15 Figure 60 is a block diagram showing the architecture of an illustrative 

CPO management central server 6000. The CPO management central server 6000 
preferably includes certain standard hardware components, such as a central processing 
unit (CPU) 6005, a random access memory (RAM) 6010, a read only memory (ROM) 
6020, a clock 6025, a data storage device 6030, and a communications port 6040. The 

20 CPU 6005 is preferably litiked to each of the other listed elements, either by means of a 
shared data bus, or dedicated connections, as shown in Figure 60. The CPU 6005 may 
be embodied as a single commercially available processor, such as Intel's Pentium 100 
MHz P54C microprocessor, Motorola*s 120 MHz PowerPC 604 microprocessor or Sun 
Microsystem's 166 MHz Ulu^PARC-I microprocessor. Alternatively, the CPU 6005 

25 may be embodied as a number of such processors operating cooperatively. 

The ROM 6020 and/or data storage device 6030 are operable to store one 
or more instructions, discussed further below in conjunction with Figures 65 and 66, 
which the CPU 6005 is operable to retrieve, interpret and execute. For example, the 
ROM 6020 and/or data storage device 6030 preferably store processes to accomplish the 

30 transfer of required payments* charges and debits, between the calling parties 5810 and 
interexchange carriers 5820-5824. 
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The CPU 6005 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as. for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from the data storage device 6030 or ROM 6020. The ALU is 
operable to perform a plurality of operations needed to carry out instructions. The CPU 
local memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 

As discussed further below in conjunction with Figures 61 through 64, 
respectively, the data storage device 6030 preferably includes a customer database 
6100, a carrier database 6200, a rate database 6300, and a CPO database 6400. The 
customer database 6100 preferably stores information on each customer of the CPO 
management system 5800, including biographical information and an indication of the 
local telephone company serving each customer. The carrier database 6200 preferably 
stores information on each carrier which is registered with the CPO management system 
5800 to provide long distance telephone service to calling parties, including address 
information. The rate database 6300 preferably stores published rate information for 
each carrier identified in the carrier database 6200. Finally, the CPO database 6400 
preferably contains a record of each CPO being processed by the CPO management 
system 5800, including the terms of the CPO and the associated status. 

In an embodiment where the CPO management system 5800 provides an 
agency feature that permits the CPO management sy.stem 5800 to accept or reject a 
given CPO on behalf of certain agency-based interexchange carriers 5820 who have 
delegated such authority to the CPO management system 5800, the CPO management 
central server 6000 preferably includes a CPO rules database (not shown) for storing the 
CPO rules. The CPO rules may be stored in a secure database to maintain the integrity 
and confidentiality of sensitive information included in each CPO rule. 

In addition, the daU storage device 6030 includes a CPO management 
process 6500. discussed further below in conjunction with Figures 65a and 65b, and an 
IVRU process 6600, discussed further below in conjunction with Figures 66a and 66b. 
Generally, the CPO management process 6500 receives each CPO from a calling party 
5810, provides the CPO to each appropriate interexchange carrier 5820 and thereafter 
determines if the terms of the offer have been accepted by any interexchange carrier 
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5820. The IVRU process 6600 is preferably invoked by the CPO management process 
6500 to receive the parameters of the CPO from the calling party 5810. 

The communications port 6040 connects the CPO management central 
server 6000 to the local switch operator 5850 and interexchange carriers 5820-5824. 
5 The communications port 6040 preferably includes multiple communication channels 
for simultaneously establishing a plurality of connections. 

DATABASES 

Figure 61 illustrates an exemplary customer database 6100 that 
preferably stores information on each customer (calling party) of the CPO management 

10 system 5800, including biographical information and an indication of the local 
telephone company serving each customer. The customer database 6100 maintains a 
plurality of records, such as records 6105-6125, each associated with a different 
customer. For each customer name listed in field 6140. the customer database 6100 
includes the customer's address in field 6145, the manner in which the customer is 

15 bound in field 6150, an indication of the local telephone company serving the customer 
in field 6155 and the customer's telephone number in field 6160. The telephone 
number stored in field 6160 may be utilized, for example, as a customer identifier to 
index a historical database (not shown) of previous transactions associated with the 
customer. 

20 As shown in field 6150, a given customer may be bound by a pre- 

existing written or electronic contract on file, which may, for example, authorize an 
accepting interexchange carrier 5820 to charge the calling party 5810 for a given call on 
the calling party's telephone statement or by means of a charge to a credit card, or other 
general-purpose account. As discussed below, the calling party 5810 may be billed for 

25 telephone calls completed in accordance with the present invention by the CPO 
management system 5800 or the local switch operator 5850, on behalf of the accepting 
interexchange carrier 5820. or directly by the accepting interexchange carrier 5820, in a 
conventional manner. 

In an implementation where a CPO obligates a calling party 5810 to 

30 achieve minimum usage for a predefined time period, for example, where a calling party 
5810 agrees to spend at least two hundred dollars ($200) over twelve (12) months to 
obtain a lower rate, the agreed upon terms can be immediately charged to a credit card. 
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or charged on a monthly basis. In addition, the credit card may not be charged unless 
the calling party 58 10 fails to meet the obligations of the CPO. For example, the calling 
party 5810 may be billed directly for calls as charges are incurred, and the remaining 
balance may be charged to the credit card account at the end of the agreed term. In 
5 addition, a calling party 5810 can be charged a penalty if the calling party 5810 does not 
agree to complete the call after the CPO is accepted by an interexchange carrier 5820. 

Figure 62 illustrates an exemplary carrier database 6200 which 
preferably stores information on each carrier which is registered with the CPO 
management system 5800 to provide long distance telephone service to calling panics, 
10 including address information. The carrier database 6200 maintains a plurality of 
records, such as records 6205-6225, each associated with a different carrier. For each 
carrier name listed in field 6240, the carrier database 6200 includes address information 
in field 6245. In addition, in an embodiment where the CPO rules of a given carrier arc 
stored in an encrypted format, or otherwise where secure transmissions are required, the 
15 cryptographic key of the associated carrier is preferably stored in field 6250 of the 
carrier database 6200. Finally, the carrier database 6200 preferably stores an indication 
in field 6255 of the percentage of CPOs which have been offered to each carrier which 
have actually been accepted by each respective carrier. In this manner, the CPO 
management system 5800 can offer a particular CPO to carriers in a sequence that is 
ranked in accordance with the CPO acceptance rate. In alternate embodiments, the 
carrier database 6200 can incorporate fields to facilitate the processing of CPOs in 
accordance with sequences based on (i) priorities negotiated by each carrier, or (ii) the 
highest commission rates paid by the carriers to the CPO management system 5800. 

Figure 63 illustrates an exemplary rate database 6300 that preferably 
stores published rate information for each carrier identified in the carrier database 6200. 
The rate database 6300 maintains a plurality of records, such as records 6305-6325, 
each associated with a different carrier. For each carrier identified in field 6340, the 
rate database 6300 preferably includes the corresponding domestic rate and international 
rate in fields 6345 and 6350, respectively. 

Figure 64 illustrates an exemplary CPO database 6400 which preferably 
contains a record of each CPO being processed by the CPO management system 5800, 
including the terms of the CPO and the associated status. The CPO database 6400 
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maintains a plurality of records, such as records 6405-6425, each associated with a 
different CPO being processed by the system 5800. For each CPO identified by CPO 
number in field 6440, the CPO database 6400 includes the date the CPO was received in 
field 6445, an identification (ID) number for the customer associated with the CPO in 

5 field 6450 and an indication of the telephone number to be called in field 6455. The 
parameters of the calling party's CPO are stored in field 6460 of the CPO database 
6400. The CPO database 6400 preferably stores the price the calling party is willing to 
pay for the call in field 6470. Field 6465 indicates the accepting carrier, once accepted 
and field 6475 records the current status of the respective CPO, such as pending. 

!0 accepted, rejected or expired. 

PROCESSES 

As discussed above, the CPO management central server 6000 preferably 
executes a CPO management process 6500, shown in Figures 65a and 65b, to receive 
each CPO from a caJling party 5810, provide the CPO to each appropriate interexchange 

15 carrier 5820 and thereafter determine if the terms of the offer have been accepted by any 
interexchange carrier 5820. As illustrated in Figure 8a, the CPO management process 
6500 begins the processes embodying the principles of the present invention during step 
6505, upon receipt of a call from a calling party 5810, for example, via a private branch 
exchange (PBX) switch of the CPO management system 5800. 

20 Thereafter, during step 6510, the CPO management process 6500 will 

extract the automatic number identification (ANI) number associated with the incoming 
call. A new record is then created in the customer database 6100 during step 6515 using 
the extracted ANI number as the customer identifier recorded in field 6160. Thereafter, 
the rVRU process 6600» discussed below in conjunction with Figures 66a and 66b, or 

25 another customer interface process, is preferably executed during step 6525 to receive 
the parameters of the CPO from the calling party 5810, including the telephone number 
of the called party 5830, the maximum price, the manner in which the CPO will be 
bound and any time limitations and other applicable restrictions. The received 
parameters of the CPO are then stored in the CPO database 6400 during step 6530, 

30 indexed by the customer identifier (ANI) and then provided to the appropriate carriers 
during step 6535 (Figure 65b). It is noted that the CPO management system 5800 can 
filter the CPOs provided to each carrier, for example, by only providing the CPO to 
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carriers who can route a call between the calling party 5810 and the desired called party 
5830 or only providing the CPOs to carriers designated by the calling party 5810. It is 
further noted that the CPO management process 6500 preferably evaluates the CPO 
against the CPO rules provided by any agency-based carriers during step 6530 as well. 

A response to the CPO is preferably received from each carrier during 
step 6540. A test is then performed during step 6545 to determine if the terms of the 
CPO have been accepted by a carrier. If it is determined during step 6545 that the terms 
of the CPO have not been accepted by acarrier. then the calling party5810 is preferably 
notified during step 6550 that the CPO has been rejected. The status of the CPO in the 
CPO database 6400 is then changed to "rejected" during step 6555. before program 
control terminates during step 6560. 

If. however, it is determined during step 6545 that the terms of the CPO 
have been accepted by a carrier, then the full customer record from the CPO database 
6400 is preferably provided to the accepting carrier during step 6570 for the carrier to 
complete the call in accordance with the terms specified by the CPO. I, is noted that the 
calling party 5810 may be billed for the call by the CPO management system 5800 or 
the local switch operator 5850 on behalf of the accepting interexchange carrier 5820. or 
directly by the accepting interexchange carrier 5820, in a conventional manner. The 
local switch operator 5850 typically receives a percentage of the total cost to complete 
the call. Finally, the status of the CPO in the CPO database 6400 is then changed to 
"accepted" during step 6575. before program control terminates during step 6580. 

As indicated above, the CPO management process 6500 preferably 
executes the IVRU process 6600. shown in Figures 66a and 66b. during step 6525 to 
receive the parameters of the CPO frem the calling party 5810. including the telephone 
number of the called party 5830. the maximum price, and any time limitations and other 
applicable restrictions. As shown in Figure 66a. the IVRU process 6600 begins the 
processes embodying the principles of the present invention during step 6610 by 
prompting the calling party 5810 for the telephone number of the called party 5830. 
Thereafter, the interactive voice response unit (IVRU) captures the response of the 
calling party 5810 during step 6620 and provides the number to be called to the CPU 
6005. 
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The IVRU then prompts the calling party 5810 for the price the calling 
party 5810 wishes to pay for the call and the manner in which the CPO will be bound, 
such as a charge to a credit card account, during step 6630, and captures the response 
during step 6640 providing the maximum price for the call to the CPU 6005. 

5 Thereafter, the IVRU prompts the calling party 5810 for any other restrictions or 
specifications associated with the CPO during step 6650, including, for example, a time 
limit for the call, one or more desired carriers, if any, and a time limit for how long the 
CPO should be pending. The IVRU then captures the response of the calling party 5810 
during step 6660 and provides the additional restrictions or specifications to the CPU 

10 6005. Finally, the FVRU process 6600 instructs the calling party 5810 to hang up and 
wait for a response during step 6670 (Figure 66b), before program control terminates 
during step 6680. 

In this manner, the restrictions of the CPO are received by the CPO 
management system 5800 and then provided to each appropriate interexchange carrier 

15 5820. If accepted, the interexchange carrier 5820 will complete the call between the 
calling party 5810 and the desired called party 5830, in accordance with the terms of the 
CPO, and the calling party 5810 is obligated to pay the accepting interexchange carrier 
5820 for the cost of the call. 

In the embodiment shown in Figure 58A, a calling party 5810 desiring to 

20 place a call to a called party 5830 picks up the telephone set 5900 and dials a telephone 
number associated with the CPO management system 5800. The call is preferably 
received by a PBX switch or a related call processor. The telephone number of the 
calling party 5810 is then extracted from the call information, and used to access or 
create a record in the customer database 6100. The calling party 5810 is then connected 

25 to either an IVRU or a live operator to submit the terms of the calling party's CPO, such 
as the number to be called and the maximum cost. The caller then is preferably 
instructed to hang up and wait for a response. 

Once the CPO is received and processed by the CPO management 
system 5800, it is then provided to a plurality of carriers. Each carrier 5820-5824 then 

30 determines whether to accept or reject the CPO, for example, based on one or more 
rules based on network capacity balancing. If the CPO is accepted, the CPO 
management system 5800 or the accepting carrier 5820 notifies the buyer and places the 
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call over the network of the accepting carrier. If there is a t.me limit or other 
restrictions associated with the call, the calling party 5810 is preferably notified at the 
time the call is initially established. The calling party 5810 may be billed for the call, 
for example, by the CPO management system 5800. the accepting carrier 5820. or by 
the local telephone company operating the local switch 5850. In this manner, the call 
may be individually charged to a general purpose account, such as a credit card, or may 
be paid for by means of the calling party's conventional telephone bill. 

Similarly, in the embodiment shown in Figure 58B, a calling party 5810 
desiring to submit a CPO for telephone service for a predefined period of time, may 
contact the CPO management system 5800 using a subscriber terminal 5815. The CPO 
can specify, for example, the rate which the subscriber is willing to pay for the 
telephone service and the length of the contractual obligation, as well as any flexibilities 
or restrictions that the calling party is willing to adhere to. in return for a discounted 
rate, such as calling during off-peak hours or a minimum spending obligation. 

Once the CPO is received and processed by the CPO management 
system 5800. the CPO is then provided to a plurality of carriers. Each carrier 5820- 
5824 then determines whether to accept or reject the CPO. If the CPO is accepted, the 
CPO management system 5800 or the accepting carrier 5820 notifies the buyer and 
switches the long distance provider for the calling party to the accepting carrier 5820. in 
an appropriate manner. 

CPO MANAGEMENT SYSTEM FOR EVENT TICKETS 
Another embodiment of the present invention will now be discussed with 
reference to Figures 67 th«)ugh 73g. The embodiment shown in Figures 67 through 73 allows 
a buyer to present a guaranteed purchase offer for a ticket to a certain event, such a hockey 
game, to a number of potential sellers. The sellers may review the offer, and accept the offer if 
the terms are agreeable. Thus, a buyer may quickly submit an offer to purchase tickets which 
are guaranteed to be delivered in a safe, convenient manner. 

With reference to Figures 67-72b. the system arehitecmre of one embodiment of 
the apparatus and method of the present invention is illustrated. As shown in Figure 67. the 
apparatus of die present invention generally comprises a venue controller 7000. a central 
controller 6800. a credit card processor 6830 and a remote user terminal 6900. The remote user 
tenninal 6900 is connected to the central controller 6800 through a network 6845. 



121 



wo 98/10361 



PCT/US97/15492 



Using the above components, the present embodiment of the invention provides 
a method and apparatus to allow a central controller to facilitate the purchase and sale of event 
tickets. Specifically, central controller 6800 receives and posts offers to purchase tickets for a 
particular event. Such offers are guaranteed, for example, using a line of credit on a credit card 
5 account. Central controller 6800 further makes each offer available to a plurality of potential 
sellers, and allows sellers to accept the offer and thereby form a legally binding contract. 

As shown in Figure 68, central controller 6800 includes central processing unit 
(CPU) 6805, random access memory (RAM) 6815, read only memory (ROM) 6820. clock 
6835, input/output ("I/O") port 6855, and data storage device 6850. The data storage device 
10 6850 is a memory device containing an event table 7 1 00, a venue table 7 1 20, a customer table 
7130, an offer table 7150, and a transaction table 71 80, discussed in greater detail with 
reference to Figures 71a through 7le, respectively. 

Figure 71a illustrates an exemplary event table 7 100 that preferably stores 
information on events for which tickets may be resold using the system of Figure 67, including 
15 location and scheduling information. Event table 7 100 maintains a plurality of records, such as 
record 71 14. each associated with a different event. For each event identifier listed in event ID 
field 7 102, event table 7100 includes an event type code stored in field 7104 and an event 
description stored in field 7106. The event type code stored in field 7104 represents the formal 
of the event, for instance, a National Hockey League game is denoted as "NHL." The event 
20 description stored in field 7 1 06 describes the specific event. 

Event table 7100 also preferably includes a venue ID stored in field 7106. The 
venue ID stored in field 7106 may be utilized, for example, to index venue table 7120, more 
fiiUy described with reference to Figure 7 lb. As shown in Figure 71a, each record stored in 
event table 7100 further includes a date stored in field 71 10 and a time stored in field 71 12. 
25 The date and time of fields 71 10 and 71 12, respectively, represent the starting time of the event 
associated with the record. The information stored in this table may be supplied to the central 
controller 6800 from any number of sources, including promoters, venues and potential buyers 
and sellers. 

Figure 71b illustrates an exemplary venue table 7120. Each record of venue 
30 table 7120, such as record 7128, preferably stores data associated with and describing a venue. 
Venue table 7120 is preferably indexed by field 7122 which stores a unique venue identifier. 
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Venue table 7120 further stores a theater, auditorium or stadium name in field 7 124 and an 
address in field 71 26. 

Figure 71c illustrates an exemplary customer table 7130 which preferably stores 
inforaiation on each customer registered with the electronic ticket sales system. Customer 
5 database 7130 maintains a plurality of records, such as records 7146 and 7148. each associated 
with a different customer. Customers registered in customer table 7 1 30 may buy tickets, sell 
Uckcts or both buy and sell tickets. Customer table 7 1 30 stores a unique customer identifier for 
each customer in field 7132 and name and address information in fields 7134 and 7136. 
Preferably, the data maintained in customer table 7 130 is provided by the customer during a 
10 registration process, at which time the customer is assigned a unique customer identifier. 

Customer table 7130 further stores customer credit card data. The customer's 
credit card number is stored in field 7138. The expiration date of the customer s credit card is 
stored in field 7140. and the name of the cardholder as it appears on the credit card is stored in 
field 7142. 

•5 Figure 7 1 d illustrates an exemplary offer table 7 1 50 that preferably stores 

information relating to offers posted using the ticket sales system of the present embodiment. 
Offer table 7 1 50 maintains a plurality of records, such as recoixls 7 1 70 and 7 1 72. each 
associated with an offer to buy or sell tickets. Each record of offer table 7 150 includes a unique 
offer identifier stored in field 7151 that is assigned by central controller 6800 when the offer is 

20 posted. Each record of offer table 71 50 includes fields for identifying the customer making the 
offer, conditions of the offer, the customer accepting the offer, and administrative information 
related to the offer. 

The customer identifier of the customer extending the offer is stored in field 
7152. Information relating to the customer extending the offer may be easily obtained using the 

25 customer identifier of field 7 1 52 as an index into customer table 7 1 30. Each record in offer 
table 7150 further stores an event identifier in field 7153. The event identifier indicates the 
event to which the offered ticket(s) relate. Information regarding the event may be easily 
obtained using the event identifier of field 7153 as an index into event table 7100. 

Each record of offer table 7150 further includes fields 7154 and 7155 that store 

30 the date the offer was made and the last day on which the offer may be accepted, respectively. 
Data indicating an offer type and offer status are also stored in each record of offer table 7 150 
in fields 7156 and 7157. Field 7156 stores a code indicating whether the offer is an offer to buy 
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or an offer to sell one or more tickets. Field 7 1 57 stores a code indicating the status of the 

offer. Offer status possibilities include: pending, active, expired and fulfilled. 

Field 71 58 of each record in the offer table stores the number of seats to which 

the offer applies. Data identifying the location of seals related to the offer populate fields 71 59- 
5 7 164. In the event an offer requires a range of seat locations, data stored in fields 7 1 59-7 1 6 1 

are used to identify the first seat in a range, and data stored in fields 7162-7164 are used to 

identify the last seat in a range. Field 7 1 65 scores the price per seat. 

In addition, each record of offer table 7150 includes administrative data in fields 

7 1 66-7 1 69. Data stored in field 7 1 66 stores an amount of credit authorized to support the offer. 
10 Once an offer has been accepted, field 7167 stores a transaction identifier that may be used as 

an index into transaction table 7180, discussed more completely with reference to Figure 71c. 

Each record of offer table 7150 optionally stores a pointer to a related, or linked, offer record. 

The pointer is stored in field 7168 and represents the offer identifier of the next related record 

in offer table 7 150. Finally, field 7 1 69 of each record of offer table 7 1 50 stores one or more 
15 serial numbers of the original tickets that a seller would like to sell. 

Once an offer is accepted, central controller 6800 adds a transaction record to 

transaction table 7 180. Figure 7 le illustrates an exemplary transaction table 7 1 80 that 

preferably stores information relating to each accepted offer. Each accepted offer is assigned a 

unique transaction identifier that is stored in field 7181 of transaction table 7180 and field 7167 
20 of offer table 7 1 50. An offer identifier of an associated record in offer table 7 1 50 is stored in 

field 7182. This offer identifier may be used as an index into offer table 7150 to retrieve 

information regarding the offer associated with a transaction record. 

Each record of transaction table 7 1 80 preferably further includes field 7 183 

which stores the date the associated offer was accepted and field 7184 which stores the total 
25 value of the transaction. Field 7185 stores the amount charged to the buyers credit card; field 

7186 stores the amount of the seller's credit line reserved to support the acceptance; and field 

7187 stores the fee charged for processing the transaction. Each record of transaction table 
7180 also stores a date in field 7188 indicating the date the ticket(s) are received by the 
operator of controller 6800. 

30 The customer identifier of the seller is stored in field 7 1 89, and data identifying 

the ticket(s) is stored in fields 7190 and 7194. Field 7190 stores the original ticket number(s), 
' and field 7194 stores new ticket number(s). The new ticket numbers are assigned to distinguish 
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original tickets from resold tickets and promote efficient resolution of potential conflicts 
between ticket holders. 

Optionally, central controller 6800 may include a contract detail table (not 
shown) containing form contract provisions which the central processor 6800 retrieves and 
5 transmits to users at various times. For example, the contract table may include a contract 
provision that is transmitted to a buyer and incorporated into the guaranteed purchase offer. 
The contract table may also include a contract provision which is transmitted to a seller prior to 
requesting an acknowledgment of his intent to bind a buyer s offer and create a legally binding 
contract. These form provisions effectively fill the gaps between conditions specified by the 

10 buyer, specifying the generic contract details common to most contracts of this nature. 

Referring now to Figure 69, remote user terminal 6900 will now be described in 
greater detail. Remote user terminal 6900 can be a personal computer, screenphone. stand alone 
kiosk, or any other device through which a customer can access the central controller 6800. 
Remote user terminal 6900 generally includes a central processing unit ("CPU") 6905 that 

15 controls the operation of remote user terminal 6900. CPU 6905 is electronically connected to a 
random access memory ("RAM") 6915, a read only memory ("ROM") 6920, an input/output 
port 6925, a clock 6935, a communication port 6940 and a data storage device 6960. CPU 6905 
receives inputs from a remote user with the input/output port 6925 and an input device 6945, 
such as a keyboard. CPU 6905 transmits outputs to a remote user via the input/output port 6925 

20 and a video monitor 6930. Further, the communication port 6940 provides the communication 
path to network 6845. Finally, the data storage device 6960 is a memory device containing 
central controller interface software 6965. 

Referring now to figure 70, venue controller 7000 will now be described in 
greater detail. Venue controller 7000 generally includes a central processing unit ("CPU") 

25 7010 that controls the operation of venue controller 7000. The CPU 7010 is electronically 
connected to a random access memory ("RAM") 7020. a read only memory ("ROM") 7030, a 
clock 7040, a communication port 7050 that provides a communication path to central 
controller 6800, and a data storage device 7060. Data storage device 7060 is a persistent 
memory device containing a ticket table 7210 and a replacement ticket table 7230. Venue 

30 controller 7000 further includes input device 7080 for receiving input data and output device 
7070 for presenting or displaying infomnation to an operator. 
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Figure 72a illustrates an exemplary ticket table 7210 that preferably stores 
information about tickets issued for various seats at a particular venue. Each ticket has a 
specific ticket number assigned to it by venue controller 7000 prior to issuance. Each record of 
ticket table 7210 preferably includes field 721 1 that identifies the event for which the ticket is 

5 valid, field 72 12 that identifies the number assigned to each ticket issued for an event, and 
fields 7214-7220 that represent the location of the seat in the auditorium (i.e. the section, row 
and seat, respectively). Ticket table 7210 could also contain fields representing other 
information specific to a venue, an event, or a seat. 

Figure 72b illustrates an exemplary replacement ticket table 7230 that preferably 

10 stores data relating to original ticket numbers that have been voided and assigned replacement 
ticket numbers. Replacement ticket table 7230 stores the ticket numbers that have been resold 
by the central controller 6800 in field 7232 and stores the replacement ticket numbers in field 
7242. Each record of ticket table 7230 further includes a field 7231 that .stores an event 
identifier and a field 7240 that stores a buyer identifier. 

15 It will be recognized by one of ordinary skill that the present invention could be 

constructed and operated without the illustrated distributed processing architecture. If venues 
and ticket distributors so desired, central controller 6800 could incorporate all or pan of the 
database of venue controller 7000 and perform all or pan of the processing steps performed by 
venue controller 7000 in the present embodiment. In such an alternate embodiment, data 

20 processing and data storage could be centralized, and venues could access the data as 
appropriate using conventional remote terminals or work stations. 

In one embodiment of the present invention, communications between potential 
buyers and sellers take place via an electronic or digital network, such as the Internet, with 
central controller 6800 hosting an Internet web site that users can access or **log on" to by 

25 means of a personal computer. It is important to note that users can access the central controller 
via other communications links such as a conventional telephone line linked to a voice response 
unit ("VRU"). 

To use the ticket reselling service, a user who is a potential buyer logs on to 
central controller 6800 through network 6845, creates and submits a guaranteed purchase offer, 
30 and disconnects from the network 6845. In one embodiment, a guaranteed purchase offer is a 
legally binding offer to purchase tickets that is backed by a pre-authorized credit card 
transaction. Upon receiving the offer, central controller 6800 contacts the buyer's credit card 
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issuer to ensure that the buyer has a valid credit card account and/or sufficient credit to pay for 
the requested tickets. The guaranteed purchase offer is then made available to potential sellers 
by posting the offer using the web site linked to central controller 6800. Periodic maintenance 
is performed by central controller 6800 to ensure that "active" offers have not expired. A 
potential seller can use the system of the present invention to browse offers and submit an 
electronic acceptance of a desirable offer. The acceptance by the potential seller is transmitted 
electronically to central controller 6800. Centra! controller 6800 processes the acceptance and 
contacts the seller's credit card issuer to ensure that there is sufficient credit to cover a potential 
penalty for non-performance. This reservation of the seller s credit is intended to promote trust 
between the parties and. thereby, protect the transaction. After verifying available credit, both 
parties are notified of the binding transaction, and the tickets are electronically voided and 
assigned a replacement ticket number. The seller is then required to surrender the voided 
tickets. This may be accomplished by returning them to the venue, or the seller may mail the 
tickets to the operator of central controller 6800. Upon receiving the surrendered tickets, the 
operator of central controller 6800 directs payment to be transferred to the user selling the 
tickets. 

With reference to Figure 73a, a process by which a user logs on and begins using 
the system will now be described. As shown in step 7300. a user operating a remote terminal 
6900 establishes a connection with the central controller 6800 through network 6845. The user 
may be either a potential buyer wishing to place a guaranteed purchase offer for tickets, or a 
potential seller wishing to review offers for tickets. 

At step 7302. central controller 6800 requests a customer ID from the user. At 
step 7304. central controller 6800 determines how to proceed based on whether or not the user 
already has a customer ID. If the user is registered with this service, and remembers his 
customer ED, he transmits his customer ID to central controller 6800 at step 73 12. and the 
process continues with step 7314. 

If. on the other hand, the user is not registered with the service, or does not 
remember his customer ID. he must submit a negative response at step 7304 and present 
relevant customer information to central controller 6800. as shown by step 7306. At step 7308. 
central controller 6800 creates a record of the customer based on the received customer 
information. This information, including name, address, credit card and number, expiration 
date, and name as it appears on the credit card, is stored in customer table 71 30. At step 73 10. 
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central controller 6800 compares the information provided by the user with information already 
stored in customer table 7 1 30. If a match is found, central controller 6800 retrieves the 
customer ED from field 7132 of customer table 7130, and transmits the customer ID number lo 
the user. This service is provided for users who have given information previously, but do not 
5 remember their customer ED number. If no match is found, the central controller 6800 assigns a 
new customer ID to the user, stores it in field 7 1 32 of customer table 71 30, and transmits it to 
the user. 

At step 7314 the user indicates whether he would like to submit a guaranteed 
purchase offer, or review offers from potential buyers. The process steps relating to submitting 
10 offers are described more fully with reference to figures 73b-73c. The process steps relating to 
reviewing offers are described more fully with reference to figures 73d-73g. In an alternative 
embodiment, the user could also elect to advertise the availability of tickets for a certain event 
to potential buyers. Furthermore, a user could elect to review such advertisements, to get a 
better understanding of what a fair price might be, prior to submitting an offer. 
15 Figures 73b and 73c illustrate the process steps executed following the u.ser s 

choice at step 73 14 to submit a guaranteed purchase offer. At step 731 6» the central controller 
transmits general venue and event information to user terminal 6900 for display to the user. 
For instance* in one embodiment, central controller 6800 may provide a number of options to 
the user in order to pinpoint the specific event that the user would like to attend. The user could 
20 directly request a particular event, or proceed through a group of narrowing choices to 

ultimately find the right event. A user, for example, may be asked to identify any of the fields 
from event table 7100. Depending on the amount of information provided, the choice of events 
will be narrowed accordingly. For instance, if the user provides only the event type (e.g. 
"NHL"), central controller 6800 scans the event table 7100 and provides all matches found in 
25 the event type field 7104. This may be a long list of events, however, central controller 6800 
may prompt the user for more information to narrow the list. The user may then select from the 
narrow list to find the event for which he is looking. For example, the user may specify only 
Saturday matinee performances of a particular Broadway production in order to narrow the list. 
Central controller 6800 then provides the user with the correct event information, including the 
30 event ID from field 7102 of the event table 7100. The user includes this event ID as part of 
their guaranteed purchase offer so that it may be tracked by central controller in the offer table 
7150. 
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Next, at step 7318, the user selects the desired event based on the event ID 
number. At step 7320. central controller 6800 requests certain information from the user 
pertaining to the offer, such as 

( 1 ) the number of tickets desired: 

(2) the price for each ticket: 

(3) the location desired for each ticket: and 

(4) optionally, a date through which the offer is valid. 

The user indicates the number of tickets he would like and the price he is willine 
to spend, based on the particular location of the tickets. The user may choose the exact 
location of seats that correspond to the price he is willing to pay using a graphical 
representation of the venue. For instance, based on the venue ID number (stored in field 7122 
of venue table 7 1 20), central controller 6800 retrieves from memory and provides to the user at 
remote user terminal 6900 a graphical representation of seating at that panicular venue. In one 
embodiment, central controller 6800 first provides a broad general outline of the entire venue 
(c.g., display by sections). The user can then click on a particular area to narrow his search for 
exact seats. With each successive selection click, the display screen at user terminal 6900 
narrows the scope of displayed seating until the user finds the seats he desires. The user can 
then select the group of seats which corresponds to the purchase offer. Central controller 6800 
stores the selected seats in fields 7159-7164 of the offer table 7150. If the user prefers to select 
one section or multiple sections instead of specific seats, he can enter a range of selections. 
Central controller 6800 then stores this broader selection by only using the section fields 7159 
and 7162. and leaving the other four fields empty. 

Further, the user may provide a close date to denote a date on which the offer 
expires. As previously discussed, central controller 6800 periodically reviews this close date, 
and changes the status of the offer to "expired" in field 7 1 57 of the offer table 7 1 50 once the 
date has passed. 

At step 7322, central controller 6800 receives the offer information transmitted 
by the user, and as shown in step 7324. central controller 6800 creates a record of the offer in 
offer table 7 150. At step 7328. the user is asked if he would like to make additional offers. At 
this point, if the user would like to make an offer for a separate event, he may go through the 
same process discussed in steps 73 16-7324. However, if the user would like to make a related, 
or linked offer to the offer previously provided, they may do so as follows. First, in one 
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embodiment they provide the same event ID as at step 73 1 8. Next, after submitting the same 
general information previously discussed, the user indicates that this offer is linked. The 
central controller then assigns the offer ID number created for the initial offer as the link ID 
number for the related offer, and stores in the link ID field 7168 of the offer table 7150. 

5 A user might provide a linked offer based on the type of seat desired. For 

instance, the user might select a number of the "high quality" seats in a particular venue, and 
offer a higher purchase price. The linked offer would include "lower quality" seats for a 
particular venue, perhaps at a lower purchase price. Thus, based on thr link ID, potential 
sellers will consider both offers together during their review. 

H) Also, the user may link offers for two separate events as opposed to the same 

one. For example, instead of linking offers based on seat selection and price, the user may 
prefer to attend one of two events in the local area, but not both. Thus, he could link these 
offers so that potential sellers would be made aware that the offers were conditioned against an 
"either/or" proposition. 

15 The central controller 6800 assigns an offer ID number to each offer in the offer 

ID field 7151, and assigns this number as the link ED number for linked offers in link ID field 
7168. Also, the offer date field 7154 is populated with a timestamp (e.g., date and time) 
indicating when the offer was posted. Next, central controller 6800 assigns the value "pending" 
to the status field 7157. This value will change to "active" upon receipt of authorization from 

20 the user s credit card issuer. Further, central controller 6800 calculates the authorized amount, 
and stores it in authorized amount field 7166. The authorized amount field represents the 
amount of the user's credit which is reserved to back up" the offer and is usually equal to the 
total transaction amount. By reserving a portion of the user s credit, the ticket seller and ticket 
service can be guaranteed that they will receive payment if the offer is accepted. In case of 

25 linked offers to buy, the authorized amount is the highest transaction amount of the linked 

offers. When a linked offer is accepted, the system automatically considers all related offers to 
be withdrawn. Finally, central controller 6800 stores all the information provided by the user, 
including the seat location based on the graphical representation of the venue, in the respective 
fields of the offer table 7150. 

30 At step 7330, the cenu-al controller 6800 extracts legal contract language from 

the contract detail table (not shown) and transmits to the user at user terminal 6900. This 
language describes the legal implications of offering the guaranteed purchase offer, and the 
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process is simiJar to reviewing terms before signing a written contract. If the user elects not to 
abide by these terms, he may cancel the offer. However, if the user does elect to abide by the 
terms, the user transmits a positive acknowledgment to central controller 6800. and is legally 
bound to the terms of the guaranteed purchase offer. 

In Figure 73c, central controller 6800 then contacts the user s credit card issuer 
at step 7332 to receive authorization for the offer. First, central controller 6800 collects the 
user name, addicss. credit card type, credit card number, and expiration date from customer 
table 7130. based on the customer ID from the offer table 7150. This information along with 
the authorization amount from field 7 1 66 of the offer table 7 1 50 is transmitted to the credit card 
issuer through credit card processor 6830. 

At step 7334. the central controller 6800 receives either an authorization or 
rejection from the credit card issuer through credit card processor 6830. The credit card issuer 
may reject the request for any number of reasons, including an expired card, overextended 
credit limit, or delinquency in payments. Upon rejection, at step 7336 central controller 6800 
notifies the user at user terminal 6900 of this rejection and requests separate credit card 
information. Alternatively, the user may transmit information corresponding to a separate 
credit card, which supplements or replaces his present information in the customer table 7130. 
If alternative credit card information is provided, step 7332 is repeated in order to receive 
authorization for the charge. Upon receiving authorization from the credit card issuer through 
the credit card processor 6830. central controller 6800 updates offer table 7120. including 
changing status field 7 1 57 to "active" to confirm the posted offer. 

Figures 73d-73g illustrate the processing steps executed based on the user s 
choice at step 7314 to review offers from potential buyers. At step 7340, central controller 
6800 transmits general venue and event information to user terminal 6900 for display to the 
user. As discussed earlier at step 73 16, central controller 6800 may provide a number of 
options to the user to identify the exact event the user wishes to review. Ultimately, central 
controller 6800 provides the user with the event ID from field 7102 of the event table 7100. At 
step 7342. the user supplies the event ID to central controller 6800 so ,t may identify associated 
offers in offer table 7150. 

At step 7344, central controller 6800 identifies offer records associated with the 
selected event ID and having an "active" status. Central controller 6800 transmits this data to 
user terminal 6900 for display to the user. The user may review all offers for the specific event 
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logeiher, or one ai a time. In one embodiment, the user may review each individual offer 
through a graphic display of the venue, to pinpoint exactly where the buyer is requesting seats. 
In some cases, the offer may be for seats anywhere in the entire arena. In others, the offer may 
only be for a specific range of sections, rows or seats. In one embodiment, the user may be able 
5 to enter their exact ticket information to confirm whether it meets the requirements of the offer. 

As previously discussed, linked offers wilt be appropriately identified upon 
presentation to the user. In this case, central controller 6800 allows associated linked offers to 
be reviewed simultaneously, so that the user can compare the conditional offers submitted from 
a single buyer. 

10 Next, at step 7346, central controller 6800 receives either a request to accept a 

particular offer, or a request to review offers for other events. In the latter case, steps 7340. 
7342 and 7346 will be repeated. It should be noted that the user may exit the system at any 
time prior to accepting an offer. 

After the user transmits a request to accept a particular offer, at step 7348 the 
15 user transmits the original ticket number and seat location (i.e. section, row and seat) to central 
controller 6800. Upon receiving this information from the user, central controller 6800 at step 
7350 transmits the original ticket number and seat location to the venue controller 7000 for 
verification of the ticket's validity. 

Referring now to Figure 73e, at step 7352 venue controller 7000 retrieves a 
20 record from ticket table 72 10 matching the ticket number transmitted by central controller 6800 
in step 7350. Venue controller 7000 verifies that the transmitted ticket number matches the 
transmitted seat location at steps 7354 and 7356. If the transmitted ticket and seal location do 
not match, at step 7358, venue controller 7000 transmits an invalid combination message to 
central controller 6800. Central controller 6800 then transmits a message to user terminal 6900 
25 indicating that the ticket number and seat location arc an invalid combination at step 7360. 
Upon receiving the invalid combination message at user terminal 6900, the user can resubmit 
the ticket and seat location to central controller 6800 at step 7370. The process then loops back 
to step 7350. If the ticket number and seat location combination is valid, the process continues 
with step 7372. 

30 At step 7372 of Figure 73f, central controller 6800 transmits to user terminal 

6900 legal contract language which is displayed to the user selling his ticket. As previously 
indicated, this contract language may be stored in a contract detail table (not shown). This 
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language describes the legal implications of accepting the guaranteed purchase offer, and the 
process is similar to reviewing terms before signing a written contract. If the user selling his 
ticket elects not to abide by these terms, the user may cancel his acceptance. However. iT the 
user elects to abide by the terms, the user transmits a positive acknowledgment to central 
controller 6800, and is legally bound to the acceptance. 

Central controller 6800 then contacts the user s credit card issuer at step 7376 to 
receive authorization for the acceptance. Central controller 6800 requests authorization from 
the credit card issuer to reserve a portion of the user's credit based on the offer information and 
credit information collected from the user at step 7306 and stored in customer table 7130. This 
credit reservation is a fraud deterrent and may be used as a penalty in the event the seller fails 
to deliver the tickets. Such a penalty creates buyer confidence and provides assurance to a user 
buying the ticket that the user selling the ticket will, in fact, relinquish the tickets. The penalty 
could be paid to the user buying the ticket if the u.ser selling the ticket attempts to repudiate the 
agreement. This penalty may be detemiined in a number of ways including imposing a flat 
penalty on the user selling the ticket or imposing a penalty equal to the entire amoum offered 
by the user buying the ticket. 

At step 7374. central controller 6800 collects information from the user selling 
the ticket. The information may include the user name, address, credit card number and 
expiration date from customer table 7130. based on the customer ID retrieved from the offer 
table 7150. This information, along with the authorization amount from field 7166 of the offer 
table 7150. is transmitted to the credit card issuer through credit card processor 6830. 

At step 7376. central controller 6800 receives either an authorization or rejection 
from the credit card issuer through credit card processor 6830. The credit card issuer may 
reject the request for any number of reasons, including an expired card, overextended credit 
limit, or delinquency in payments. Upon rejection, at step 7328 central controller 6800 notifies 
the user at user terminal 6900 of the rejection and requests alternate credit card information. 
The user may attempt to transmit the same credit information as provided earlier, because the 
user may have mistakenly transmitted incorrect information earlier. Alternatively, the user mav 
transmit information corresponding to an alternate credit card, which will supplement or 
replace the credit card information in customer table 7130. Further, the user could cancel the 
transaction altogether. If alternative credit card information is provided, step 7374 is repeated 
m order to receive authorization for the charge. 
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If central controller 6800 receives authorization from the credit card issuer 
throueh credit card processor 6830. the process continues with step 7380 wherein central 
controller 6800 generates and assigns a transaction ID to the sale. This transaction ID is stored 
in field 7167 of the offer table 7150. Further, central controller 6800 creates a new record in 
5 transaction table 7180, indexed by the assigned transaction ID. The assigned transaction ID is 
also stored in field 71 8 1 of transaction table 7 1 80. The original ticket number 7 1 90 field of 
transaction table 7180 is populated with the appropriate ticket nuniber(s) from the user selling 
the ticket. Further, central controller 6800 timestamps the acceptance using date field 7183 
indicating when the acceptance was posted. 
(Q Once the guaranteed purchase offer has been accepted, central controller 6800 

uses the customer ID from field 71 52 as an index into customer table 7 1 30 to retrieve the name 
of the user buying the ticket. At step 7382. central controller 6800 transmits the name of user 
buying the ticket to the venue controller 7000. 

At step 7384, venue controller 7000 creates a new record in replacement ticket 
15 table 7230. The new record is populated with information indicating the buyer *s name, the 
original ticket number, the section, row and seat of the ticket. As shown at step 7386, the new 
record is further populated with a replacement ticket number assigned by venue controller 
7000. The replacement ticket number is then transmitted to central controller 6800 

Once central controller 6800 has received the replacement ticket number 7242 
20 from venue controller 7000, central controller 6800 then updates the new ticket number field 
7 194 of transaction table 7 180 at step 7388. At step 7390, central controller 6800 determines 
the payment due and charges the credit card, of the user buying the ticket, the price of the ticket 
plus a processing fee 7 1 87. Central controller 6800 also updates field 7 1 85 of the transaction 
table 7 1 80 with the amount charged. Finally, central controller 6800 updates field 7 1 89 with 
25 the seller ID of the user accepting the offer, and central controller 6800 updates field 7 186 with 
the seller amount authorized in the event that the seller tries to use his sold ticket. Field 7 1 84 
is updated based on buyer amount charged 71 85 less the processing fee 7 1 87. Although fees of 
the present embodiment are illustrated as being stored in a table, such fees could easily be 
calculated instead of being retrieved from a table. 
30 At step 7392, central controller 6800 transmits a message to user terminal 6900 

to notify the user selling the ticket that it will credit his credit card account with the sale amount 
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of the ticket as soon as central controller 6800 receives verification thai the original tickets have 
been surrendered. 

At step 7394 the central controller transmits replacement ticket number 7292 
and a message to the user buying the ticket indicating that his guaranteed offer has been 
5 accepted. The user buying the ticket may then prim the replacement ticket number, take it to 
the venue and use it to gain access to the desired event, at step 7396. The cancellation of the 
original number and issuance of a replacement ticket number tied to the purchasing user's name 
is done in order to prevent fraud by either the ticket seller and/or the purchaser. 

For instance, if a seller arrives at a venue with a ticket, and a purchaser also 

10 arrives to the same venue with a replacement ticket for the same seat, the venue controller can 
be accessed to determine which ticket is valid. The replacement ticket always supersedes the 
original ticket, provided it is registered in the replacement ticket table 7230 of the venue 
controller 7000. If such fraud is attempted by the seller and detected by central controller 6800. 
the central controller can charge the seller*s credit card account the seller amount authorized in 

15 field 856 of transaction table 7 1 80. 

As another example, if two people arrive at the venue with the same replacement 
ticket, the venue controller can be accessed to determine the rightful owner, based on the 
contents of the new buyer name field 7240, of replacement ticket table 7230. These measures 
taken against fraud will assure customers that there will be no problems in using central 

20 controller 6800 to buy and sell tickets. 

Finally, at step 7398, central controller 6800 receives verification that the 
original ticket has been received from the seller, and credits the credit card account of the user 
selling the ticket with the transaction amount 7184. Central controller funher updates the date 
tickets received field 71 88 accordingly. Surrender of the ticket is preferably accomplished by 

25 delivery of the ticket to a will call window of the venue, however other surrender arrangements 
are possible, such as through the postal service or Federal Express. Once the ticket has been 
surrendered and the transaction is complete, central controller 6800 updates status field 7157 of 
the offer table 7 1 50 to "completed" for tracking purposes. Upon receipt of the surrendered 
tickets, central controller 6800 credits the account of the user selling the tickets. 

30 Although the preferred method of suirendering the original tickets is using the 

mail or other delivery mechanism, numerous alternate embodiments are possible. Using one 
alternate embodiment, ticket redemption could be constructively accomplished at the lime an 
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offer to buy is irrevocably accepted. The alternate embodiment employs event tickets that can 
be physically altered to render them invalid or void. Each ticket includes a unique ticket 
number that is prc-printed on the face of the ticket, but obscured from view by a scratch-off 
covering, such as an opaque latex coating. The ticket number is unknown to the ticket holder 

5 unless the scratch-off covering is removed. 

At the time of acceptance, the seller possessing the tickets is instructed to 
remove the covering over the ticket number on each ticket to be sold. The ticket number is 
provided to central controller 6800 to verify that the ticket seller is, in fact, in posse^ision of 
valid tickets. The ticket number provided for each ticket involved in the transaction is then 

10 electronically voided and replacement ticket number is assigned as previously described. 

The act of revealing the ticket number not only serves to verify the ticket seller's 
possession of the tickets, but also eliminates the need for the seller to surrender the tickets 
because removal of the scratch-off covering voids the tickets. While this alternate embodiment 
requires additional structure with respect to the event tickets, it eliminates the need to reserve a 

15 portion of the seller's credit line as a penalty for failing to return the unused tickets. 

An illustrative example of the invention will now be described using the data 
populating various fields of the figures. Record 7172 of the offer table 71 50 is a guaranteed 
offer to buy as indicated by type field 7 156 that has been submitted by user 4000 as identified 
by customer ID field 7 1 52. User 4000. as denoted by record 7 148 in the customer table 7 1 30 is 

20 Sue Black, residing at 101 Pink Ave in Norwalk, CT. The credit card number submitted to 
central controller 6800 is Discover card number ^M4^ ^414 - 4444 - 4444 that expires 9/02 and 
was issued to Susan Black. 

In record 7172 of the offer table 71 50, Sue Black has posted a guaranteed offer 
to buy two tickets to event ID EOOl, as denoted by event ID field 7153, for $200.00 per ticket 

25 in the first row of the first section of the venue. As denoted by record 7 1 1 4 of event table 7 1 00, 
event EOOl is an NHL game, specifically NJ Devils vs. New York Rangers, occurring on 5/6/97 
at 7:30 PM at "MSG" as denoted by venue ID field 7108. Record 7126 of venue table 7120 
identifies MSG as the Madison Square Garden venue in New York. NY. 

In addition to this guaranteed purchase offer. Sue Black has also posted a link 

30 offer as denoted by linked ID field 7 1 68. This linked offer has an ID code of 0333. Record 

7 170 of offer table 71 50 has the offer ID 0333, and is therefore the offer that is linked to record 
7172. Record 7170 is an offer by Sue Black to purchase four tickets to the NHL game NJ 
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Devils vs. New York Rangers having the same date and time as the offer request of record 
7172. In record 7170, Sue Black indicates that she will pay $250 each for four tickets in the 
first row of the first section of the venue. Because offer 7170 is linked to offer 7172. Sue Black 
has indicated that she would like one or the other of the two offers. 

Field 7166 of offer table 7150 indicates that $1,000 has been authorized by 
Discover for account ^11 . 1 . 1^.1 ^1 -4444.4444 for both records 7170 and 7172. submitted by Sue 
Black. S 1 .000 is the maximum possible amount that Sue Black's offers could cost her if one of 
them is fulfilled. 

For record 7172. the transaction ID field 7167 has been populated with a 
transaction ID. indicating that a buyer has accepted Sue Black's guaranteed offer to buy. Status 
field 7157 of record 7172 registers that the offer has been fulfilled, and the status record 7170 is 
expired, since it was linked to record 7172 in a way indicating that if one was filled, the other 
should be disregarded. 

Record 7 1 95 of transaction table 7 1 80 describes the detail of transaction TROO 1 . 
which is the acceptance of Sue Black's guaranteed offer to buy by seller 2000. as indicated by 
seller ID field 7189. 

Record 7 1 70 of the customer table 7 1 30 indicates that customer having the ID 
number 2000. as indicated by customer ID field 7132. is Jill Janson. residing in 456 Red Drive. 
Atlanta GA, and having Master Card number 2222-2222-2222-2222 with expiration date 9/99 
registered with central controller 6800. 

Record 7195 indicates that Sue Black was charged S420 on 5/2/97 for her 
purchase of .seats 003 and 004 of row l.seat 1 of the event tied to the record of her guaranteed 
purchase offer in offer table 7150. Record 7195 also indicates that Jill Janson has sold her 
original ticket numbers 667913 and 667914, stored in the original ticket number field 810. for 
section 001. row 001. and seat 003 and 004. The seller amount authorized field 7185 stores 
$400. the amount that central controller 6800 has been authorized by Mastercard to debit from 
account 2222-2222-2222-2222 in the event that Jill Janson does not honor her agreement to sell 
her tickets. All or a portion of this amount can be credited to Sue Black if there is a problem 
using her new ticket number for access to the venue event. 

The date tickets received field 7188 is blank for this record, indicating that 
central controller 6800 has not yet received verification that Jill Janson has surrendered her 
tickets. Once central controller 6800 has received verification that Jill Janson has suirendered 
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her tickets, Jill Janson's credit card account will be credited $380, the amount stored in 
transaction amount field 7 1 84. 

Central controller 6800 has issued replacement ticket numbers to Sue Black for 
both seats. These replacement ticket numbers are stored in field 7194. Preferably, Sue Black 
5 will print out these replacement ticket numbers and take them with her to the venue to gain 
access to the event. 

Records 7222 and 7224 of ticket table 7210 store information relating to the 
original tickets issued to Jill Janson. Records 7244 and 7246 of replacement ticket table 7230 
store the replacement ticket numbers issued by central controller 6800 to Sue Black, which 
10 replace the original ticket numbers given to Jill Janson, These records are stored by venue 
controller 7000 to be used in the event of fraud as previously described. 

It is important to note that in the embodiment described above, the notification 
of the panics, both buyer and seller is performed through contacting their respective remote 
user terminals. This notification can also be performed using conventional technology including 
15 but not limited to telephone, facsimile, e-mail and paging. 

In addition to the guaranteed offer and acceptance system of the present 
invention, the present embodiment is also well suited for other aspects of ticket resale. For 
example, the present embodiment can include a registration process for certain events or 
tickets. Such a process would enable a prospective ticket buyer to set up a ticket watch which 
20 could be implemented by central controller 6800. Central controller 6800 could periodically 
poll offers to determine if specific tickets are available. Availability could be transmitted to a 
user via conventional telephone lines, E-maiL facsimile or pager. A notification preference 
could be determined by the user during the registration process. 

Another aspect of ticket resale that is well suited to the present embodiment is 
25 advertising. Instead of simply allowing users to place, review and accept offers, the system 
could provide advertising for products related to events and tickets. 

CPO AND THIRD PARTY INPUT MANAGENT SYSTEM 
The method and apparatus of another embodiment of the present 
invention, which allows sellers to evaluate the acceptability of an offer from a buyer in 
30 light of information relevant to the offer from a third party, will now be discussed with 
reference to Figures 74 through 82. Although the description which follows in 
conjunction with Figures 74 through 82 employs a finance-related embodiment for 
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purposes of illustration, those skilled in the art will understand Uiat the scope of the 
present invention is not limited thereto. Accordingly, in the description below, sellers 
and buyers may be referred to as lenders and borrowers, respectively. 

Referring to Figure 74, a system 7410 for processing the sale of products 
comprises a central controller 7412 which communicates with a borrower terminal 
7414, third parties 7416 and 74 1 8, and lender terminals 7420, 7422 and 7424 via the 
Internet or other suitable communication network. The illustrated numbers of borrower 
terminals, third parties and/or lender terminals arc illustrative, not limiting. It will be 
understood by those skilled in the art that any number of borrower terminals, third 
panics and/or lender terminals may communicate with the central controller 741 2 in 
alternate embodiments of the present invention. 

The borrower terminal 7414 is typically a computer or other apparatus 
for generating and transmitting signals to the central controller 74 1 2. Ideally, the 
borrower terminal is a conventional personal computer, such as one based on an Intel 
80386 microprocessor, that is connected to a modem or other remote communication 
device. A customer desiring to purchase a product (good or service) operates the 
borrower terminal 7414 to transmit an offer signal including at least one condition 
signal to the central controller 7412. The offer signal defines a conditional purchase 
offer having at least one condition from the customer. 

In the present embodiment, the customer is a "borrower" who desires to 
obtain a loan (i.e., he desires to "purchase" a loan). Accordingly, the offer signal 
defines an offer to obtain a loan. As described in detail below, the offer may comprise 
any of a variety of conditions, and so the offer signal comprises one or more condition 
signals specifying the borrower's desired conditions. For example, the borrower may 
desire a particular monthly payment amount for the loan and/or a particular interest rate. 

The borrower terminal 7414 also transmits to the central controller 7412 
a payment identifier signal for specifying a general-purpose account fix>m which funds 
may be paid. The payment identifier signal specifies, for example, a credit card number 
or checking account number of an account owned by the borrower. 

The payment identifier signal is used to effectively "bind" the borrower 
by identifying funds to be paid if the borrower fails to carry out (consummate) his offer 
to purchase. The payment idenUfier thereby assures potemial lenders that the offer is 
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genuine and binding. For example, if the borrower reneges, the payment identifier may 
be used to collect an amount of funds sufficient to offset the lender's costs in processing 
the borrower's offer. The specific amount of funds to collect can be either set by the 
central controller 7412, or may be left to the discretion of the lender. 
5 In other embodiments, the payment identifier may additionally be used to 

collect other fees, even if the borrower consummates his offer. For example, the 
payment identifier may be used to collect loan transaction fees or even monthly loan 
payments. 

If a lender operates a lender terminal to accept the offer, thereby 
10 incurring costs processing the offer, the lender is assured that he (i) may sell the loan to 
the borrower if he can satisfy the loan conditions; or (ii) if the borrower fails to abide by 
the terms of the offer (e.g., the borrower fails to consummate the loan), the lender 
collects a penalty payment paid from the account specified by the payment identifier 
signal. In both cases, the lender is assured that acceptance of the offer will yield funds, 
15 and thus acceptance of the offer is not as risky as in other systems for processing the 
sale of products. 

As described above, sellers often require information relevant to the offer 
from a third party in order to determine whether to accept the offer. For example, the 
offer signal from the borrower would not be evaluated and accepted by a lender unless 

20 the lender knew the borrower's credit history or credit score. Accordingly, the system 
7410 includes third parties 7416 and 7418 for providing the central controller 7412 with 
informational signals. The informational signals desirably define any information that 
(i) should not be viewed and/or altered by the buyer, and/or (ii) is necessary to 
determine the validity and/or value of the offer. The third parties 74 1 6 and 74 1 8 may 

25 be, for example, a credit-reporting bureau, which provides the central controller 74 1 2 
with credit information about the borrower, and an appraiser for appraising the value of 
loan collateral submitted by the borrower. 

The central controller 7412 receives and stores the transmitted offer 
signal, payment identifier signal and informational signal. As described in detail below, 

30 the signals are stored in several databases, thereby facilitating the searching for and 
retrieval of data represented in the databases. The central controller 7412 uses the 
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Stored signals to allow any of the lender terminals 7420. 7422 and 7424 to accept the 
offer, if the offer is considered adequate. 

If a lender terminal accepts the offer, the borrower is bound to abide by 
the terms of the offer. If the borrower does not. for example if the borrower does not 
sign the necessary loan paperwork, the central controller 74 12 initiates the u.se of the 
payment identifier signal to collect the funds. For example, the central controller 74 1 2 
may transmit the payment identifier signal to the lender terminal, thereby allowing the 
lender to collect the funds. Alternatively, the central controller 7412 may jtself use the 
payment identifier signal to collect the funds. 

The central controller 7412 may manage the acceptance of offers in 
various ways. In embodiments described below, accepting an offer can include (i) 
transmitting the offer signal to lender terminals, and in lum receiving acceptance signals 
from lender terminals, or (ii) comparing the offer signal with seller's rules, and 
determining whether the offer satisfies any of the rules. 

Figure 75a illustrates a central controller 7530, which is an embodiment 
of the central controller 7412 (Figure 74) that is used when accepting an offer includes 
the step of receiving acceptance signals from lender terminals. The central controller 
7530 includes a central processing unit 753 1, such as one or more conventional 
microprocessors, and a storage device 7532. such as a RAM, floppy disk, hard disk or 
combination thereof, which is connected to the central processing unit 753 1 . The 
central processing unit 7531 and the storage device 7532 may each be (i) located 
entirely within a single computer; (ii) connected thereto by a remote communication 
link, such as a serial port cable, telephone line or radio frequency transceiver: or (iii) a 
combination thereof. For example, the central controller 7530 may comprise one or 
more computers connected to a remote server computer for maintaining databases. 

The storage device 7532 stores (i) a program 7533 for controlling the 
central processing unit 753 1 in accordance with the present invention, and particularly 
in accordance with the processes described in detail hereinaften (ii) a borrower database 
7534 for maintaining information on each borrower who submits an offer, (iii) a lender 
database 7536 for maintaining information on each lender who may accept an offer; (iv) 
an offer database 7538 for specifying each offer submitted to the central controller: (v) a 
credit report database 7540 for storing infomiational signals describing credit 
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worthiness; (vi) a collateral database 7542 for storing informational signals describing 
collateral used in connection with the offers; and (vii) a response database 7544 for 
specifying each acceptance received by the central controller. 

The program 7533 also includes necessary program elements, such as 
5 "device drivers" for interfacing with computer peripheral devices. Appropriate device 
drivers and other necessary program elements arc known to those skilled in the art, and 
need not be described in detail herein. Each of the databases 7534, 7536, 7538, 7540, 
7542 and 7544 are described in detail below. 

Figure 75b illustrates a central controller 7560, which is an embodiment 
10 of the central controller 7412 (Figure 74) that is used when accepting an offer includes 
the step of determining whether the offer satisfies any lender-specified mies. The 
central controller 7560 includes a central processing unit 756 1 and a storage device 
7562 connected to the central processing unit 7561 . The central processing unit 7561 
and the storage device 7562 may each be implemented in a manner similar to the central 
15 processing unit 753 1 and the storage device 7532 of Figure 75a- 

The storage device 7562 likewise stores (i) a program 7533 for 
controlling the central processing unit 7561 in accordance with the present invention; 
(ii) a borrower database 7534 for maintaining information on each borrower who 
submits an offer; (iii) a lender database 7536; (iv) an offer database 7538; (v) a credit 
20 report database 7540; and (vi) a collateral database 7542; and further stores (vii) a rules 
database 7564 for storing lender-specified rules for accepting offers. The program 7533 
and the databases 7534, 7536, 7538, 7540 and 7542 function as described above, and 
the rules database 7564 is described in detail below. 

Referring to Figure 76, the borrower database 7534 of Figures 75a and 
25 75b stores exemplary records 7670 and 7672, each of which corresponds to a borrower 
who submits an offer. Each record stores an offer identifier 7674 that is generated by 
the central controller 7412 (Figure 74) and uniquely identifies an offer made by the 
borrower. Each record also stores the name 7676, address 7678 and telephone number 
7680 of the borrower. 

30 Referring to Figure 77, the lender database 7536 of Figures 75a and 75b 

stores exemplary records 7790 and 7792, each of which corresponds to a lender who 
may accept an offer. Each record stores a lender identifier 7794 that is generated by the 
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central controller 7412 (Figure 74) and uniquely identifies a lender, as well as the name 
7796, address 7798 and telephone number 7800 of the lender. 

Referring to Figure 78. the offer database 7538 of Figures 75a and 75b 
stores exemplary records 7810, 7812 and 7814. each of which corresponds to a received 
offer; Each record stores an offer identifier 7816 that (i) uniquely identifies an offer, 
and (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 
of Figure 76. Each record further stores the date 78 18 and time 7820 at which the offer 
was received, and conditions of the offer, such as a loan amount 7822, a monthly 
payment 7824, a loan term 7826 and a loan interest rate 7828. Each record may also 
have an expiration date 7830 and expiration lime 7832. after which the corresponding 
offer may not be accepted. A loan type 7834 may also be stored in embodiments where 
it is desirable for lenders to know, for example, whether the desired loan is secured. 

Referring to Figure 79. the credit report database 7540 of Figures 75a 
and 75b stores exemplary records 7942. 7944 and 7946, each of which corresponds to a 
received offer. Each record stores an offer identifier 7948 that (i) uniquely identifies an 
offer, (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 
of Figure 76, and (iii) corresponds to one of the offer identifiers 78 1 6 in the offer 
database 7538 of Figure 78. For each offer, there is also stored a credit report identifier 
7950 that is generated by the central controller 7412 (Figure 74) and uniquely identifies 
the results of a credit check or other evaluation of a borrower who submitted the 
corresponding offer. A credit score 7952 defines the results of that evaluation. 

Referring to Figure 80, the collateral database 7542 of Figures 75a and 
75b stores exemplary records 8060, 8062, 8064 and 8066, each of which corresponds to 
a received offer. Each record stores an offer identifier 8068 that uniquely identifies an 
offer and corresponds to the offer identifiers described above in connection with Figures 
76, 78 and 79. For each offer, there is also stored the type 8070 of collateral, a 
description 8072 of the collateral and a value 8074 of the collateral. 

Referring to Figure 8 1 a, the response database 7544 of Figure 75a stores 
exemplary records 8 1 80 and 8 1 82, each of which corresponds to a received response to 
an offer. Each record stores an offer idenUfier 8184 that uniquely identifies an offer and 
corresponds to the offer identifiers described above in connection with Figures 76. 78. 79 
and 80. Each record also stores a response identifier 8 1 86 that uniquely identifies each 
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received response, a lender identity 8 1 88, and conditions of the loan that the lender is 
willing to provide, such as a loan amount 8190, a periodic payment amount 8192, a loan 
term 8194 and a loan interest rate 8196. The time 8198 and date 8200 of the response 
are also stored in the response database 7544. 
5 Referring to Figure 81b, the rule database 7564 of Figure 75b stores 

exemplary records 8212 and 8214, each of which corresponds to a rule defining criteria 
for when a lender will accept an offer. Each record stores a nile identifier 82 16 that 
uniquely identifies a rule, a lender identity 8218 identifying the lender who accepts 
offers satisfying the rule and rule restrictions 8220 which specify the criteria for 
10 accepting an offer. 

Figures 82a and 82b illustrate a method 8230 for processing sales of a 
loan between a borrower terminal and one or more lender terminals. The illustrated 
method 8230 is performed by the central controller 7530 of the embodiment of Figure 
75a, in which accepting an offer includes receiving acceptance signals from lender 
15 terminals. The central controller receives from the borrower terminal an offer signal 
(step 8232). As described above, the offer signal includes at least one condition signal, 
and the offer signal thereby defines an offer having at least one condition from a 
borrower. 

A payment identifier signal is received from the borrower terminal (step 
20 8234). The payment identifier signal, such as a credit card number or checking account 
number, specifies an account from which funds may be paid. 

The central controller validates the payment identifier signal (step 8236). 
The payment identifier signal may be validated by freezing an amount of funds in the 
account or otherwise making the funds unavailable to the borrower and thereby ensuring 
25 that such funds remain available to an accepting seller. If the payment identifier signal 
is not valid, the borrower terminal is requested to retransmit the offer and payment 
identifier signal (step 8238). The central controller also validates the received offer 
signal (step 8240), thereby determining whether the received offer signal meets 
predetermined validation criteria. If the offer signal does not meets the predetermined 
30 validation criteria, the borrower terminal is requested to retransmit the offer and 
payment identifier (step 8238). 
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Validation typically comprises performing a financial calculation to 
determine whether the received offer signal defines a meaningful offer. For example, if 
an offer signal includes a loan amount, interest rate, loan period and monthly payment 
amount, a financial calculation can determine whether the specified offer is meaningful. 
Financial calculations are known, and described in Chapter Three of "Principles of 
Corporate Finance, Fourth Edition", by Richard A. Brealey and Stewan C. Myers, 
incorporated herein by reference as part of the present disclosure. 
The central controller also requests and receives an informational signal including citdil 
information from a third party (step 8242). The informational signal may further 
include other information relevant to the offer, such as an appraisal value of collateral 
offered by the borrower. As described above, more than a single third party may supply 
desired informational signals to the centra! controller. 

The central controller then transmits the offer signal and the 
informational signal(s) to one or more lender terminals (step 8244). The central 
controller in turn receives, from at least one of the lender terminals, one or more 
acceptance signals responsive to the transmitted offer signal and informational signal 
(step 8246). One of the acceptance signals is selected (step 8248). and the 
corresponding lender terminal is identified (step 8250). The borrower is thereby bound 
to the identified lender under the terras and conditions of the offer. If the borrower later 
reneges by not abiding by the terms of the offer (step 8252), use of the payment 
identifier signal is initiated in order to collect the funds (step 8254). For example, the 
central controller may collect the funds, or may transmit the payment identifier signal to 
the identified lender terminal, allowing the lender to directly collect the funds. 

The step 8248 of selecting one acceptance signal may be performed in a 
number of ways. For example, the first received acceptance signal or a random one of 
the acceptance signals may be selected. In still another embodiment, the acceptance 
signals may be sorted according to a predetermined sort criteria, such as sorted by 
lowest interest rate or lowest monthly payment amount. Selecting the first of the sorted 
acceptance signals would then provide the lowest interest rate or monthly payment, 
respectively. A number of "tie-breaking" methods may be used to select one acceptance 
signal from a group of equally attractive acceptance signals. 



145 



wo 98/10361 



PCT/US97/15492 



It may also be desirable to allow the borrower to select the acceptance 
signal, and thus choose the lender. In such an embodiment, a plurality of lender signals 
is transmitted to the borrower. Each lender signal indicates a lender, which in turn 
corresponds to one of the plurality of acceptance signals. The borrower terminal then 
5 provides the central controller with a selection signal indicative of a selected lender 
signal. The selection signal thereby indicates a corresponding acceptance signal, which 
is selected. 

Selection of an acceptance signal may also occur through a condition 
specified by the offer. For example, an offer may comprise condition signals indicative 

10 of a loan amount, a periodic payment amount and a request for a lowest interest rate. 
Thus, the acceptance signal indicating the lowest interest rate received within a 
predetermined time is selected. Similarly, an offer may comprise condition signals 
indicative of a loan amount, an interest rate and a request for a lowest periodic payment 
amount. Such an offer may further comprise a condition signal indicative of a 

15 maximum loan period. Accordingly, the acceptance signal indicating the lowest 
periodic payment amount is selected. 

Figure 82c illustrates another embodiment of a method 8260 for 
processing sales of a loan between a borrower terminal and one or more lender 
terminals. The illustrated method 8260 is performed by the central controller 7560 of 

20 the embodiment of Figure 75b, in which accepting an offer includes comparing the offer 
signal with seller*s rules, and determining whether the offer satisfies any of the rules. 

As described above in connection with Figures 82a and 82b, the central 
controller receives from the borrower terminal an offer signal (step 8262), and also 
receives a payment identifier signal {step 8264). The central controller validates the 

25 payment identifier signal (step 8266). If the payment identifier is not valid, the borrower 
terminal is requested to retransmit the offer and payment identifier (step 8268). The 
central controller also validates the received offer signal (step 8270), thereby 
determining whether the received offer signal meets predetermined validation criteria. If 
the offer is not meaningful, the borrower terminal is requested to retransmit the offer and 

30 payment identifier (step 8268). The central controller also requests and receives an 
informational signal including credit information from a third party (step 8272). 
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The central controller stores at least one rule signal from each of a 
plurality of sellers (step 8274). Each rule signal includes at least one seller-defined 
restricuon. Some restrictions may involve offer conditions, while other restrictions may 
involve the informational signal. For example, a mle may include the restrictions that 
the loan amount must be less than $100,000 and the credit score must be greater than 
eighty. It will be understood by those skilled in the art that the step 8274 of storing the 
rule signals may occur either before or after the offer signal is received. 

The offer signal and the informational signal are compared with at least 
one rule signal (step 8276). If it is determined that the conditions of the offer and the 
informational signal satisfy each seller-defined restriction of any rule (step 8278). the 
corresponding lender is identified (step 8280). If more than one rule is satisfied, one 
rule is selected in accordance with any of the methods described above. The borrower 
is thereby bound to the identified lender under the terms and conditions of the offer. If 
the borrower later reneges by not abiding by the terms of the offer (step 8282). use of 
the payment identifier signal is initiated in order to collect the funds (step 8284). as 
described above. 

Those skilled in the art will recognize that the method and apparatus of 
the present invention has many applications, and that the present invention is not limited 
to the representative examples disclosed herein. Moreover, the scope of the present 
invention covers conventionally known variations and modifications to the system 
components described herein, as would be known by those skilled in the art. 
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1 . A computer device for consummating a binding contract between a 

5 remote prospective buyer and a remote potential seller, comprising: 
a memory device; and 

a processor disposed in communication with said memory device, said 
processor configured to receive from the remote prospective buyer (a) a purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
10 purpose financial account from which fiinds may be paid for a purchase meeting said at 
least one condition; said processor further configured to transmit the purchase offer to a 
plurality of remote potential sellers, and receive from at least one of the remote potential 
sellers an unconditional acceptance of the offer. 

15 2. The computer device of claim 1 , wherein said processor is 

further configured to initiate the use of the payment identifier to effect payment for the 
purchase from the buyer. 

3. The computer device of claim 1 , wherein the general purpose financial 
20 account is a credit card account. 

4. A computer device for consummating a binding contract between a 
remote prospective buyer and a remote potential seller, comprising: 

a memory device; and 

25 a processor disposed in communication with said memory device, said 

processor configured to receive from the remote prospective buyer (a) a purchase offer 
containing at least one condition, and (b) a payment identifier for specifying a general 
purpose financial account of an electronic settlement system from which funds may be 
paid for a purchase meeting said at least one condition; said processor fuither 

30 configured to transmit the purchase offer to an electronic buying network of remote 
potential sellers, receive from at least one of the remote potential sellers an 
unconditional acceptance of the offer, and initiate the use of the payment identifier to 
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render payment for said purchase by charging said general purpose financial account of 
said electronic settlement system. 

5. The computer device of claim 4 wherein said electronic settlement 
system is a credit card system. 

6. The computer device of claim 4 wherein said electronic settlement 
system is separate from said electronic buying network. 

7. The computer device of claims I or 4. wherein the at least one condition 
is selected from the group consisting of price, quantity, delivery date, quality, 
geographic location, and anonymity. 

8. The computer device of claims 1 or 4. wherein the processor is 
configured to notify a first-accepting seller that it has entered into a legally binding 
contract with the buyer. 

9. The computer device of claims 1 or 4, wherein the processor is further 
configured to transmit notification to the buyer that the purchase offer was accepted by 
a first-accepting seller. 

10. The computer device of claim 9. wherein the notification to the buyer of 
acceptance identifies a first-accepting seller. 

11. The computer device of claims I or 4. wherein the purchase offer 
includes an expiration date and is non-revocable prior to that date. 

12. The computer device of claims I or 4, wherein the purchase offer expires 
if it is not accepted within a predetermined time period. 
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13. The computer device of claims I or 4, wherein the processor is further 

configured to notify the buyer that the purchase offer has lapsed if the purchase offer 
expires without being accepted. 

5 14. The computer device of claims 1 or 4, wherein the purchase offer is not 

valid until a predetermined date. 

1 5. The computer device of claims 1 or 4, wherein the processor is further 
configured to determine whether the offer has been revoked prior to any acceptance. 

to 

16. The computer device of claims 1 or 4, wherein the purchase offer 
contains the condition that the buyer has the right to withdraw its offer after the first- 
accepting seller accepts the offer provided that the buyer pays a specified penalty to the 
first-accepting seller. 

15 

17. The computer device of claims I or 4, wherein the purchase offer is 
cryptographically signed by the prospective buyer. 

18. The computer device of claims 1 or 4, wherein the processor is further 
20 configured to collect payment for the purchase from the buyer. 

19. The computer device of claims 1 or 4, wherein the processor is further 
configured to transmit buyer credit card information and authorization to the first- 
accepting seller. 

25 

20. The computer device of claims 1 or 4, wherein the processor is further 
configured to place payment collected from the buyer in an escrow account. 

21 . The computer device of claims I or 4, wherein the payment for the 
30 purchase is collected from the buyer on an installment basis. 
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22. The computer device of claims I or 4, wherein the processor is further 
configured to remit payment for the purchase to the first-accepting seller. 

23. The computer device of claims 1 or 4. wherein the processor is further 
configured to transfer payment from the buyer to the first-accepting seller. 

24. The computer device of claim 23. wherein the payment for the purchase 
is remitted to the first-accepting seller immediately upon acceptance of the purchase 
offer. 

25. The computer device of claims 1 or 4, wherein the processor is further 
configured to authenticate at least one of the origin and integrity of transmissions 
exchanged between the potential buyer and potential .sellers. 

26. The computer device of claims 1 or 4. wherein the processor is further 
configured to make the purchase offer available to potential sellers without identifying 
the prospective buyer. 

27. The computer device of claims 1 or 4. wherein the processor is further 
configured to notify the buyer that their offer was accepted without revealing the 
identity of the seller. 



28. 

goods. 



The computer device of claims I or 4. wherein the purchase offer is for 



29. A method of electronically consummating a binding contract between a 

remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the remote prospective buyer (a) a purchase 
offer containing at least one condition, and (b) a payment identifier for specifying a 
general purpose financial account from which funds may be paid for a purchaije meeting 
said at least one condition; 
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electronically making available the purchase offer to a plurality of 
remote potential sellers; and 

electronically receiving from at least one of the remote potential sellers 
an unconditional acceptance of the offer. 

5 

30. The method of claim 29, wherein the at least one condition is selected 

from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

10 3 1 . A method of electronically consummating a binding contract between a 

remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the prospective buyer a purchase offer 
containing at least two conditions, one condition stating that the buyer shall have the 
right to choose from among a plurality of acceptances from potential sellers ai least one 
!5 acceptance to which the prospective buyer shall be bound; 

electronically making available the purchase offer to a plurality of 
potential sellers; 

electronically receiving from a plurality of the potential sellers 
unconditional acceptances of the offer; 
20 electronically transmitting the plurality of unconditional acceptances to 

the prospective buyer; and 

electronically receiving from the prospective buyer at least one election 
of an unconditional acceptance under which the buyer will be bound to perform. 

25 32. The method of claim 3 1 , wherein one of said two conditions is selected 

from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

33. A method of electronically consummating a binding contract between a 

30 remote prospective buyer and a remote potential seller, which comprises the steps of: 

electronically receiving from the remote prospective buyer (a) a purchase 
offer containing at least one condition, and (b) a payment identifier from a general 
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purpose financial account of an electronic settlement system from which funds may be 
paid for a purchase meeting said at least one condition; 

electronically making available the purchase offer to a electronic buying 
network of remote potential sellers; 

electronically receiving from at least one of the remote potential sellers 
an unconditional acceptance of the offer; and 

electronically initiating use of the payment identifier to render payment 
for said purchase by charging said general purpose financial account of said electronic 
settlement system. 

34. The method of claim 33 wherein said electronic settlement system is a 
credit card system. 

35. The method of claim 33 wherein said electronic settlement system is 
separate from said electronic buying network. 

36. The method of claim 33. wherein the at least one condition is selected 
from the group consisting of price, quantity, delivery date, quality, geographic location, 
and anonymity. 

A system for processing airline ticket sales, comprising: 
a communications port for obtaining a purchase offer for travel from a 
customer and one or more rules from a plurality of sellers of airline tickets, said 
purchase offer containing at least one customer-defined coridition and each of said rules 
containing one or more airline-defined restrictions; and 

processing means for comparing said purchase offer to said mles to 
determine whether any of said sellers of airline tickets is willing to accept said purcha.se 
offer if said customer-defined conditions satisfy said airline-defined restrictions of at 
least one of said rules. 



38. 



A system for processing the sale of goods or services, comprising: 
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a communications port for obtaining a purchase offer from a customer 
for the purchase of said goods or services and one or more rules from a plurality of 
sellers, said purchase offer containing at least one customer-defined condition and each 
of said rules containing one or more seller-defined restrictions; and 
5 a processor for comparing said purchase offer to said rules to determine 

whether any of said sellers is willing to accept said purchase offer if said customer- 
defined conditions satisfy said seller-defined restrictions of at least one of said rules. 

39. The system according to claim 37 or 38, wherein said purchase offer is 
10 binding. 

40. The system according to claim 37 or 38, wherein said processor 
identifies a product satisfying said customer-defined conditions. 

15 41. The system according to claim 37 or 38, wherein said restrictions include 

a price and said price is not disclosed. 

42. The system according to claim 37 or 38, wherein said processor 
provides an acceptance of said purchase offer to said customer if said customer-defined 

20 conditions satisfy said restrictions. 

43. The system according to claim 37 or 38, wherein said processor binds 
said customer if said customer-defined conditions satisfy said restrictions. 

25 44. The system according to claim 37 or 38, further comprising one or more 

remote servers for storing at least a portion of said rules. 

45. The system according to claim 37 or 38, further comprising at least one 

revenue management system and wherein at least a portion of said mles are generated 
30 by said at least one revenue management system. 
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46. The system according to claim 37 or 38, wherein said processor 
generates a counteroffer if said purchase offer is not accepted and said purchase offer is 
within a predefined tolerance of at least one of said rules. 

47. The system according to claim 37 or 38, wherein said restrictions include 
a minimum price and said processor prevents said customer from identifying said 
minimum price. 

48. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by limiting the number of said purchase 
offers which may be obtained from a given customer in a predefined period. 

49. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by assessing a penalty to said customer 
if a ticket is not booked when an airline accepts said purchase offer. 

50. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by evaluating a rating of said customer 
containing information regarding the likelihood that said customer will book a ticket 
corresponding to said purchase offer. 

51. The system according to claim 47, wherein said processor prevents said 
customer from identifying said minimum price by binding said customer to purchase 
said airiine ticket if said customer-defined conditions satisfy said airline-defined 
restrictions. 

52. A system for processing the sale of airiine tickets, said system 
comprising: 

an inventory allocation system for providing a plurality of seats for sale 
to customers who submit a purchase offer for travel, said purchase offer containing at 
least one customer-defined condition including a price; 
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a revenue management system for establishing airline-defined 
restrictions that are applicable to said provided seats including an appropriate fare; and 

a transmitter for providing said airline-defined restrictions to a processor 
to determine whether to accept said purchase offer if said customer-defined conditions 
5 satisfy said airline-defined restrictions. 

53. The system according to claim 52, a receiver for obtaining a reservation 
for one or more of said provided seats if said customer-defined conditions satisfy said 
airline-defined restrictions. 

10 

54. The system according to claim 52, wherein said revenue management 
system allocates a fare class containing said plurality of seats for sale to said customers 
who submit said purchase offer. 

15 55. The system according to claim 52, wherein said revenue management 

system further comprises a processor for establishing rules for generating a 
counteroffer if said purchase offer is within a predefined tolerance of at least one of said 
airline-defined restrictions. 

20 56. The system according to claim 52, wherein said revenue management 

system selects said airiine-defined restrictions to discourage use by customers typically 
willing to pay full fare. 

57. A method of processing airline ticket sales, comprising the steps of: 

25 obtaining a purchase offer for.travel from a customer, said purchase offer 

containing at least one customer-defined condition including a price; 

identifying one or more rules fi-om a plurality of sellers of airline tickets, 
each of said rules containing one or more airiine-defined restrictions; and 

comparing said purchase offer to said rules to determine whether any of 
30 said sellers of airiine tickets is willing to accept said purchase offer if said customer- 
defined conditions satisfy said airiine-defined restrictions of at least one of said rules. 



156 



wo 98/10361 



PCT/US97/15492 



58. A system for processing cruise ticket sales, comprising: 

a communication port for obtaining a purchase offer for travel from a 
customer and for receiving one or more rules from a plurality of sellers of cruise tickets, 
said purchase offer containing at least one customer-defined condition including a price 
5 and each of said rules containing one or more cruise operator-defined restrictions; and 

a processor for comparing said purchase offer to said rules to determine 
whether said customer-defined condition satisfies each of said cruise operator-defined 
restrictions of at least one of said rules. 

10 59. A system for processing cruise ticket sales comprising: 

a conununications port for obtaining a purchase offer for said cruise 
ticket from a customer and for providing said purchase offer to a plurality of potential 
sellers of said cruise tickets, said purchase offer containing at least one customer- 
defined condition and a payment identifier for specifying a general-purpose account 
15 from which funds may be paid; and 

a processor for determining if one or more of said carriers accepts said 
purchase offer and for binding said customer to purchase said cruise ticket if an 
acceptance is received for said purchase offer. 

20 60. The system according to claim 58, wherein said cruise operator-defined 

restrictions include a price and said price is not disclosed. 

61 . The system according to claim 58 or 59. wherein said customer-defined 
condition includes a specified itinerary. 

25 

62. The system according to claim 58 or 59, wherein said customer-defined 
condition includes a level of service. 

63. The system according to claim 58 or 59, wherein said customer-defined 
30 condition includes a maximum price. 

64. A system for processing the sale of a product, comprising: 
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a communication port for obtaining a purchase offer for said product 
from a customer, said purchase offer containing at least one customer-defined condition 
and a payment identifier for specifying a general-purpose account from which funds 
may be paid; 

5 a processor for determining if a plurality of potential sellers of said 

product accept said purchase offer and for identifying said plurality of accepting sellers 
to said customer; and 

said communication port receiving a selection from said customer of one 
of said accepting sellers to provide said product. 

10 

65. The system according to claim 64, wherein said processor provides a 
channel of communication between said buyer and said accepting sellers. 

66. The system according to claim 64, wherein said processor provides an 
15 electronic representation to said buyer of said product provided by each of said 

accepting sellers. 

67. The system according to claim 64, wherein said processor provides 
incentives to said buyer for selecting one of said accepting sellers to provide said 

20 product. 

68. A system for processing the sale of a product comprising: 

a communications port for obtaining a purchase offer from a customer, 
said purchase offer containing at least one customer-defined condition and a payment 
25 identifier for specifying a general-purpose account from which funds may be paid; and 

a processor for (i) determining if one or more of said carriers accepts said 
purchase offer and identifies a product satisfying said customer-defined condition and 
(ii) binding said customer to purchase said cruise ticket if an acceptance is received for 
said purchase offer. 

30 
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69. A system for processing the sale of a product, comprising: 

a communications port for obtaining a purchase offer from a customer, 
said purchase offer containing at least one customer-defined condition and a payment 
identifier for specifying a general -purpose account from which funds may be paid; 
5 a processor for determining if a plurality of potential sellers accept said 

purchase offer and for binding said customer to purchase from one of said plurality of 
accepting sellers; and 

a memory device for storing an identifier of said additional acceptances 
for comparison by said processor against purchase offers from subsequent customers. 

10 

70. The system according to claim 69, wherein said identifier of said 
additional accepted products is stored in a memory cache which is accessed before said 
providing step for said purchase offers from subsequent customers. 



15 71. A system for processing the sale of a product, comprising: 

a communications port for: 

(a) obtaining a purchase offer from a customer for the purchase of said 
product, said purchase offer containing at least one customer-defined 
condition including a subset of preferred sellers from a set of 

20 potential sellers; 

(b) providing said purchase offer to one or more excluded sellers in said 
set of potential sellers who are not preferred sellers; and 

(c) receiving from one of said excluded sellers a counteroffer to said 
purchase offer before said purchase offer is accepted by one of said 

25 preferred sellers; and 

a processor for determining if said customer accepts said counteroffer. 

72. The system according to claim 71, wherein said communication port 

receives an acceptance from said customer to purchase said product from said excluded 
30 counteroffering seller. 
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73. The system according to claim 71, wherein said processor binds said 
customer to purchase said product from said excluded counteroffering seller. 

74. The system according to claim 71, wherein said purchase offer is 
5 provided to said excluded sellers before said preferred sellers. 

'75. The system according to claim 71. wherein said purchase offer is 

provided to said excluded sellers contemporaneously with said preferred sellers. 

>0 76, The system according to claim 64, 68, 69 or 7 U wherein said product is a 

good or service. 

77. The system according to claim 76, wherein said good or service is an 
airline ticket. 

15 

78. The system according to claim 76, wherein said good or service is a 
cruise. 

79. The system according to claim 76, wherein said good or service is one or 
20 more long distance telephone calls. 

80- A method of processing cruise ticket sales, comprising the steps of: 

obtaining a purchase offer for travel from a customer, said purchase offer 
containing at least one customer-deflned condition; 
25 identifying one or more rules from a plurality of sellers of cruise tickets, 

each of said rules containing one or more cruise operator-defined restrictions; and 

binding said customer to purchase said cruise ticket if said customer- 
defined condition satisfies each of said cruise operator-defined restrictions of at least 
one of said rules. 



30 



81- A method of processing cruise ticket sales, comprising the steps of: 
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obtaining a purchase offer for said cruise ticket from a customer, said 
purchase offer containing at least one customer-defined condition and a payment 
identifier for specifying a general-purpose account from which funds may be paid; 

providing said purchase offer to a plurality of potential sellers of said 

cruise tickets; 

receiving from one or more of said sellers an acceptance of said purchase 

offer; and 

binding said customer to purchase said cruise ticket if an acceptance is 
received for said purchase offer. 

82. A system for processing the sale of a package of component items 
comprising: 

a communications pon to receive a purchase offer for said package from 
a customer, said purchase offer containing a description of each component item and a 
payment identifier for specifying a general-purpose account from which funds may be 
paid; and 

a processor to deconstruct said package purchase offer into a plurality of 
component purchase offers and to determine if each of said component purchase offers 
are accepted by one or more potential sellers and thereby bind said customer to purchase 
said package if an acceptance is received for each of said component purchase offers. 

83. A system for processing the sale of a package of component items 
comprising: 

a communications port for obtaining a purchase offer for said package 
from a customer and for obtaining one or more rules from a plurality of sellers of said 
component items, said purchase offer containing at least one customer-defined 
condition for each of said component items and each of said rules containing one or 
more seller-defined restrictions; and 

a processor to: 

deconstruct said package purchase offer into a plurality of component 
purchase offers; 
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compare one or more of said component purchase offers to said rules to 
determine whether any of said sellers is willing to accept said component purchase offer 
if said customer-defined condition satisfies said seller-defined restrictions of at least one 
of said rules; and 

5 provide said package of component items to said customer if an 

acceptance is obtained for each of said component purchase offers. 

84. A system for processing the sale of a package of component items 
comprising: 

JO a communications port to receive a purchase offer for said package from 

a customer, said purchase offer containing a description of each component item and a 
payment identifier for specifying a general -purpose account from which funds may be 
paid; and 

a processor to determine if each of said component purchase offers are 
15 accepted by one or more potential sellers and thereby bind said customer to purchase 
said package if an acceptance is received for each of said component purchase offers. 

85. The system according to claim 82 or 84, wherein said processor initiates 
the use of said payment identifier to collect said funds. 

20 

86. The system according to claim 82, 83 or 84, wherein said component 
purchase offers are offered at a component price. 

87. The system according to claim 86, wherein said component price of each 
25 component is based on the percentage of the market value of the component item to the 

market value of the total package. 

88. The system according to claim 82, 83 or 84, wherein said processor 
initiates the entering of a preliminary agreement with each seller accepting a component 

30 purchase offer, whereby the component item associated with said accepted component 
purchase offer is reserved for a predefined time period. 
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89. The system according to claim 82. 83 or 84, wherein said purchase offer 
includes a total price and a portion of said total price is reserved as a margin. 

90. The system according to claim 86, wherein said processor increases the 
5 component price of one or more of said component purchase offers that remain 

unaccepted by said sellers after a predefined time period. 

91. The system according to claim 82, 83 or 84, wherein said processor 
filters said component purchase offers provided to said sellers based on the industry 

10 associated with each component purchase offer and the industry of said sellers. 

92. The system according to claim 82, 83 or 84, wherein said acceptance 
further includes an identification of a component product satisfying said customer- 
defined condition. 

15 

93. A system for processing the sale of a package of component items 
comprising: 

a communications port to receive a purchase offer for said package from 
a customer, said purchase offer containing a description of each component item and a 
20 payment identifier for specifying a general-purpose account from which funds may be 
paid; and 

a processor to deconstruct said package purchase offer into a plurality of 
component purchase offers and to determine if each of said component purchase offers 
are accepted by one or more potential sellers at a component price and thereby bind said 
25 customer to purchase said package if an acceptance is received for each of said 
component purchase offers, wherein said component prices are not disclosed to said 
customer. 

94. A mediod of processing the sale of a package of component items. 
30 comprising the steps of: 
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obtaining a purchase offer for said package from a customer, said 
purchase offer containing a description of each component item and a payment 
identifier for specifying a genera) -purpose account from which funds may be paid; 

deconstructing said package purchase offer into a plurality of component 
5 purchase offers; 

determining if one or more potential sellers accept said component 
purchase offers; and 

binding said customer to purchase said package if an acceptance is 
received for each of said component purchase offers. 

10 

95. A method of processing the sale of a package of component items, 
comprising the steps of: 

obtaining a purchase offer for said package from a customer, said 
purchase offer containing at least one custonrier-defined condition for each of said 
15 component items; 

deconstructing said package purchase offer into a plurality of component 
purchase offers; 

identifying one or more rules from a plurality of sellers of said 
component items, each of said rules containing one or more seller-defined restrictions; 
20 and 

comparing one or more of said component purchase offers to said rules 
to determine whether any of said sellers is willing to accept said component purchase 
offer if said customer-defined condition satisfies said seller-defined restrictions of at 
least one of said rules; and 
25 providing said package of component items to said customer if an 

acceptance is obtained for each of said component purchase offers. 

96. A system for processing long distance calls comprising: 

a communications port for obtaining a purchase offer from a customer 
30 for one or more telephone calls and for providing said purchase offer to a plurality of 
potential carriers, said purchase offer containing at least one customer-defined condition 
and a payment identifier for specifying a manner in which funds will be paid; and 
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a processor for determining if one or more of said carriers accepts said 
purchase offer and for binding said customer to purchase said telephone calls if an 
acceptance is received for said purchase offer. 

97. A system for processing long distance calls, comprising: 

a communication port for obtaining a purchase offer from a customer for 
one or more telephone calls and for receiving one or more rules from a plurality of 
carriers, said purchase offer containing at least one customer-defined condition 
including a price and each of said rules containing one or more carrier-defined 
restrictions; and 

a processor for comparing said purchase offer to said rules to determine 
whether any of said carriers is willing to accept said purchase offer if said customer- 
defined condition satisfies each of said carrier-defined restrictions of at least one of said 
rules. 



system according to claim 96, wherein said processor initiates 
the use of said payment identifier to collect payment. 

system according to claim 96. wherein said funds may be paid 
from a general purpose account. 

' The system according to claim 96. wherein said funds are charged 

to a periodic telephone service bill issued by a telephone service provider. 



101. The system according to claim 96 or 97. wherein said purchase offer 
received from a telephone set configured to transmit said purchase offers. 

1 02. The system according to claim 96 or 97. wherein said purchase offer is 
for a package of calls to one or more called parties. 

103. The system according to claim 96 or 97. wherein said purchase offer is 
for a telephone service contract for a predefined period of time. 



IS 
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104. The system according to claim 96 or 97, wherein said purchase offer is 

for a telephone service contract for a predefined amount of money. 

5 1 05. The system according to claim 96 or 97, wherein said customer-defined 

condition specifies a particular time of day for said one or more telephone calls. 

106. The system according to claim 96 or 97, wherein said customer-defined 
condition specifies a minimum duration for said one or more telephone calls. 

10 

107. The system according to claim 96 or 97, wherein said customer-defined 
condition specifies a maximum duration for said one or more telephone calls. 

108. The system according to claim 96 or 97, wherein said customer-defined 
15 condition includes a telephone number of a party to be called. 

109. The system according to claim 96 or 97, wherein said communication 
port is connected to a telephone network. 

20 1 10. The system according to claim 96 or 97, wherein said communication 

port is connected to an electronic network. 

111. A method of processing long distance calls, comprising the steps of: 

obtaining a purchase offer from a customer for one or more telephone 
25 calls, said purchase offer containing at least one customer-defined condition and a 

payment identifier for specifying a manner in which funds will be paid; 

providing said purchase offer to a plurality of potential carriers; 
receiving from one or more of said carriers an acceptance of said 

purchase offer; and 

30 binding said customer to purchase said telephone calls if an acceptance is 

received for said purchase offer. 
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112. A method of processing long distance calls, comprising the steps of: 

obtaining a purchase offer from a customer for one or more telephone 
calls, said purchase offer containing at least one customer-defined condition including a 
price; 

identifying one or more rules from a plurality of long distance carriers, 
each of said rules containing one or more carrier-defined restrictions: and 

binding said customer to purchase said telephone calls if said customer- 
defined condition satisfies each of said carrier-defined restrictions of at least one of said 
rules. 



113. A computer device for consummating a binding contract between a remote 
prospective event ticket buyer and a remote potential event ticket seller, comprisins: 

a memory device: and 

a processor disposed in connection with said memory device, said 
processor configured to: 

receive from said buyer a purchase offer for an event ticket, said 
offer containing at least one condition, an account number from a general 
purpose financial account, and authorization to charge said general purpose 
financial account for a purchase meeting said at least one condition; 

transmit said purchase offer to a plurality of remote potential event ticket sellers 

receive from at least one of said remote potential event ticket sellers an 
unconditional acceptance of said offer: 

determine a replacement ticket identifier associated with said event ticket: and 

transmit said replacement ticket identifier to said buyer. 

1 14. The device of claim 1 1 3 wherein said processor is further configured to receive 
a second general purpose financial account number from said seller and authorization to charge 
said second general purpose account number for a penalty applied to an account of said seller. 

115. The device of claim 1 1 3 wherein said processor is further configured to process 
payment to said seller upon receiving a signal representing surrender of said event ticket by 
said seller. 
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1 16. The device of claim 1 13 wherein said processor is further configured to process 

payment to said seller upon receiving a ticket number associated with said event ticket. 

5 117. The device of claim 1 1 3 wherein said processor is further configured to process 

a cancellation of said event ticket. 

1 1 8. The device of claim 1 1 3 wherein said processor is further configured to receive 
and store a name of said buyer associated with said event ticket. 

10 

1 19. The device of claim 1 13 wherein said processor is further configured to transmit 
to a venue controller a ticket identifier associated with said event ticket. 

120. The device of claim 1 19 wherein said processor is configured determine said 
15 replacement ticket identifier by being further configured to receive said replacement ticket 

identifier from said venue controller. 

121. The device of claim 1 13 wherein said replacement ticket identifier includes an 
original ticket identifier. 

20 

1 22. A computer device for managing replacement identifiers for event tickets, 
comprising: 

a memory device; and 

a processor disposed in connection with said memory device, said processor 
25 configured to receive from a central controller a request for a replacement ticket number, said 
request including an original ticket number, said processor further configured to determine said 
replacement ticket number, transmit said replacement ticket number to said central controller: 
and store said original ticket number and said associated replacement ticket number at said 
memory device. 

30 

123. The device of claim 122 wherein said processor is further configured to receive 
identity data representing an identity of a buyer, and store said identity data at said 
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memory device for association with said original ticket number and said replacement 
ticket number. 

124. A computer device for authenticating replacement identifiers for event tickets, 
5 comprising: ^ 

a memory device for storing a ticket identifier and a first replacement ticket 
identifier associated with said ticket identifier; 
an output device; and 

a processor disposed in connection with said memory device and said output 
10 device, said processor configured to: 

electronically receive a second replacement ticket identifier: 

compare said second replacement ticket identifier to said first replacement ticket 
identifier to determine a result: and 

display said result via said output device to indicate the validity of said second 
15 replacement ticket identifier. 

125. The device of claim 124 wherein said memory further stores data representing 
an identity of a buyer associated with said first replacement ticket identifier, and said processor 
is further configured to retrieve said identity data and display said identity data via said output 

20 device to indicate said identity of said buyer. 

126. A method of processing sales of items, comprising: 

receiving an offer signal including at least one condition signal, the offer 
25 signal thereby defining an offer having at least one condition from a customer: 

receiving a payment identifier signal for specifying an account from 
which funds may be paid; 

receiving an informational signal relevant to the offer from a third party; 
transmitting the offer signal and the informational signal to at least one 

30 seller; 

receiving from at least one of the at least one seller an acceptance signal 
responsive to the transmitted offer signal and the transmitted informational signal: and 
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selecting one acceptance signal. 



1 27. An apparatus for processing sales of items, comprising: 
a storage device; and 

5 a processor connected to the storage device, 

the storage device storing a program for controlling the processor; and 
the processor operative with the program to: 

receive an offer signal including at least one condition signal, the 
offer signal thereby defining an offer having at least one condition from a 
10 customer, 

receive a payment identifier signal for specifying an account from 
which funds may be paid, 

receive an informational signal relevant to the offer from a third 

party, 

'5 transmit the offer signal and the informational signal to at least 

one seller, 

receive from at least one of the at least one seller an acceptance 
signal responsive to the transmitted offer signal and the transmitted 
informational signal, and 
20 selecting one acceptance signal. 

128. The apparatus of claim 127, wherein the processor is further operative 
with the program to: 

identify the seller from which the selected acceptance signal was 

25 received. 

129. The apparatus of claim 1 27, wherein the processor is further operative 
with the program to: 

initiate the use of the payment identifier signal to collect the funds. 

30 

1 30. The apparatus of claim 1 29, wherein the processor is further operative 
with the program to transmit the payment identifier signal to the at least one seller. 
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131. The apparatus of claim 1 27, wherein the processor is further operative 
with the program to: 

validate the received offer signal, and thereby determine whether the 
5 received offer signal meets predetermined validation criteria. 

1 32. The apparatus of claim 131, wherein the processor is further operative 
with the program to transmit the offer signal and the informational signal only if the 
step of validating determines that the received offer signal meets the predetermined 

10 validation criteria. 

1 33. The apparatus of claim 1 27, wherein the processor is further operative 
with the program to select the first received acceptance signal. 

15 1 34. The apparatus of claim 127, wherein the processor is further operative 

with the program to select a random one of the plurality of acceptance signals if a 
plurality of acceptance signals are received. 

135. The apparatus of claim 127, wherein the processor is further operative 
20 with the program to 

if a plurality of acceptance signals are received, 

sort the plurality of acceptance signals according to a 
predetermined sort criteria, and 

select the first of the sorted plurality of acceptance signals. 

25 

136. The apparatus of claim 127, wherein the processor is further operative 
with the program to 

if a plurality of acceptance signals are received, 

transmit a plurality of seller signals, each indicative of a seller 
30 which corresponds to one of the plurality of acceptance signals, 

receive a selection signal indicative of a selected seller signal, 
and thereby indicate a corresponding acceptance signal, and 
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select the acceptance signal corresponding to the selected seller signal. 

1 37. An apparatus for processing sales of a loan between a borrower terminal 
and at least one lender terminal, comprising: 

a storage device; and 

a processor connected to the storage device, the borrower terminal and 
the at least one lender terminal, 

the storage device storing 

a program for controlling the processor; and 
the processor operative with the program to 

receive from the borrower terminal an offer signal including at 
least one condition signal, the offer signal thereby defining an offer having at least one 
condition from a borrower, 

receive from the borrower terminal a payment identifier signal for 
specifying an account from which funds may be paid, 

receive an informational signal including credit information from 

a third party, 

transmit the offer signal and the informational signal to the at 
least one lender terminal, 

receive from at least one lender terminal an acceptance signal 
responsive to the transmitted offer signal and the transmitted informational signal, 

select one acceptance signal, and 

identify the lender terminal from which the selected acceptance 

signal was received. 

138. The apparatus of claim 1 37, wherein the processor is further operative 
with the program to: 

validate the received offer signal, and thereby determine whether the 
received offer signal meets predetermined validation criteria. 

139. The apparatus of claim 1 38, wherein the processor is further operative 
with the program to: 
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perform a financial calculation to determine whether the received offer 
signal defines a meaningful offer. 

140. The apparatus of claim 1 37, wherein the at least one condition signal 

indicates at least one of a loan amount, a periodic payment amount, a loan period and an 

interest rate. 



141. The apparatus of claim 137, wherein the at least one condition signal 

indicates a request for a lowest of one of a periodic payment amoiint and an interest 



rate. 



1 42. The apparatus of claim 1 37. wherein the offer signal includes: 
a first condition signal indicative of a loan amount. 

a second condition signal indicative of a periodic payment amount, and 
a third condition signal indicative of a request for a lowest interest rate. 

143. The apparatus of claim 142. wherein the processor is further operative 
with the program to: 

if a plurality of acceptance signals are received, wherein each acceptance 
signal includes an interest rate, select an acceptance signal having the lowest interest 
rate of the plurality of acceptance signals. 

144. The apparatus of claim 1 37, wherein the offer signal includes: 
a first condition signal indicative of a loan amount, 

a second condition signal indicaUve of a request for a lowest periodic 
pajonent amount, and 

a third condition signal indicative of an interest rate. 

145. The apparatus of claim 144. wherein the processor is further operative 
with the program to: 
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10 



15 



if a plurality of acceptance signals are received, wherein each acceptance 
signal includes a periodic payment amount^ select an acceptance signal having the 
lowest periodic payment amount of the plurality of acceptance signals. 

146. The apparatus of claim 144, wherein the offer signal further includes: 
a fourth condition signal indicative of a loan period. 

147. The apparatus of claim 144, wherein the offer signal further includes: 
a fourth condition signal indicative of a maximum loan period. 

148. The apparatus of claim 1 37, wherein the offer signal includes: 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a periodic payment amount, and 
a third condition signal indicative of an interest rate. 

149. The apparatus of claim 148, wherein the second condition signal is 
indicative of a monthly payment amount. 



150. The apparatus of claim 148, wherein the offer signal further includes: 
20 a fourth condition signal indicative of a loan period. 

151. The apparatus of claim 137, wherein the offer signal includes 
a first condition signal indicative of a loan amount, 

a second condition signal indicative of a loan period, and 
25 a third condition signal indicative of an interest rate. 

1 52. The £^paratus of claim 151, wherein the offer signal further includes: 
a fourth condition signal indicative of a periodic payment amount. 

30 153. The apparatus of claim 152, wherein the fourth condition signal is 

indicative of a monthly payment amount. 



174 



wo 98/10361 



PCT/US97/15492 



1 54. An apparatus for processing sales of items, comprising: 

a storage device; and 

a processor connected to the storage device, the borrower terminal and 
the at least one lender terminal, 

the storage device storing 

a program for controlling the processor; and 
the processor operative with the program to 

receive an offer signal inclijding at least one condition signal, the offer 
signal denning an offer having at least one condition from a customer, 

receive a payment identifier signal for specifying an account from 
which fiinds may be paid; 

receive an informational signal relevant to the offer from a third 

party; 

store at least one role signal from each of a plurality of sellers, 
each role signal including at least one seller-defined restriction; 

compare the offer signal and the informational signal with at least 

one role signal; and 

determine whether the at least one condition and the 
informational signal satisfy each seller-defined restriction of any role. 

155. The apparatus of claim 154. wherein the processor is further operative 

with the program to: 

if a plurality of roles are satisfied, select one of the plurality of satisfied 

roles. 



156. The apparatus of claim 155, wherein the processor is further operative 

with the program to: 

select a random one of the plurality of satisfied roles. 



157. The apparatus of claim 155. wherein the processor is ftjrther operative 

with the program to: 



175 



WO9gn0361 



1/115 



PCT/US97/15492 




Q 
O 



< lU o 
Z CO O /->! 

lZ ^ cc 

iH 

Oa_0 



uj Q 
^ $ i o 

O ffi 

DC rr 



£2 









a 


LU 




1 




_l 


a: 


LU 




CO 


i 







UJ O °- O 
UJ — ' ^ 

o 
o 



< liJ 

z: CO 

S ^ 
p X cc 

^ O UJ 

Q cc u. 

^ Z3 ^ 

O 5. O 
o 



UJ 

CO 

s 

CO 

UJ <=> 



CO 



F o 
o 



LU 
UJ UJ 



Q 
O 



< UJ CD 

Z CO o 

o < ^ 
cz X oc 

5 Z> *JL 



S IJLI O 
^ CO O 

2 ? ^ 

p X cc 

5 oc U- 
z — > U- 

O 5. O 



UJ 

o 
o 



[71U 



o 



cc 

UJ 

>- 



UJ O 

CO P 

o 

o 



wo 98/10361 



PCT/US97/15492 



2/115 



RAM 



215 



CRYPTOGRAPHIC 
PRCWESSOR 

210 



CLOCK 



OPERATING 
SYSTEM 

240 



ROM 



CPU 
205 



PAYMENT 
PROCESSOR 

m. 



QAIA STORAGE 
DEVICE 250 



BUYER 
DATABASE 255 

SELLER 
DATABASE 260 

CPO 
DATABASE 265 

COUMTER-OFFER 
DATABASE 267 

SELIER RESPONSE 
DATABASE 270 

BUYER 
ACCOUNT 297 



PURCHASE CONRRMATION 
DATABASE 275 

CONTRACT DETAIL 
DATABASE 280 

PAYMENT 
DATABASE 285 

CYRPTOGRAPHIC KEY 
DATABASE 290 

AUDIT 
DATABASE 295 

SELLER 
ACCOUNT 298 



ESCROW 
ACCOUNT 299 



CENTRAL 
CONTROLLER 200 



5 



ICTWORK 
INTERFACE 
245 



▼ 

TO BUYERS 
AND SELLERS 



FIG. 2 



wo 98/10361 



PCT/US97/15492 



3/115 



VIDEOMONITOR 



SELLER INTERFACE 
300 



VIDEO 
DRIVER 



CLOCK 



RAM 

315 



CRYPTOGRAPHIC 
PROCESSOR 

aifi 



CPU 



DATA STORAGE 
DEVICE 360 



MESSAGE 
DATABASE 



AUDIT 
DATABASE 



ROM 
320 



COMM. 
PORT 



340 



2ZQ 



5 



380 



TO CENTRAL 
CONTROLLER 
200 



MODEM 
350 



BIOMETRIC 
DEVICE 




FIG. 3 



wo 98/10361 



PCTAJS97/15492 



4/115 




BUYER INTERFACE 
400 



5 



VIDEO 
DRIVER 



CLOCK 
435 



RAM 
415 



CRYPTOGRAPHIC 
PROCESSOR 
410 



CPU 



405 



DATA STORAGE 
DEVICE 460 



ROM 

m 



COMM. 
PORT 



442 



/ MESSAGE 




\ DATABASE 


m ( 


/ AUDIT 




\ DATABASE 


480 [ 



TO CENTRAL 
CONTROLLER 
200 



MODEM 
45fi 



BIOMETRIC 
DEVICE 
455 




FIG. 4 



wo 98/10361 



PCT/US97/15492 



5/115 



BUYER LOGS ON TO CENTRAL 
CONTROUER 



I 



SELECTS SUaECT OF GOODR 

510 




AIRLINE TICKET. HOTEL ROOM. RENTAL 




CAR. INSURANCE. MORTGAGES 

515 


1 






DESCRIBES GOODS 












^ V 






PROVIDES OTHER CONDITIONS 




FLIGHT MUST ARRIVE BEFORE 
MIDNIGHT, HOTEL ROOM MUST BE 


4 


NON-SMOKING. CAR MUST NOT BE A 
COMPACT 

535 






ADDS EXPIRATION DATE 






MO 







I 



ADDS PRICE 






Sgfi 



ADOS BUYER ID NUMBER 



CENTRAL CONTROLLER RECEIVES 
DATA FROM BUYER 

570 

i — 



ADDS LEGAL LANGUAGE TO FORM 
CONDmONAL PURCHASE OFFER 



FIG. 5 



wo 98/10361 



PCTAJS97/1S492 



6/115 



CENTRAL CONTROLLER EXTRACTS 
PRICE AND EXPIRATION DATE FROM 



CPO 



m 



REQUESTS MERCHANT APPROVAL 
CODE i=OR TRANSACTION FROM 
CREDIT CARD CLEARING HOUSE 

m 




NO 



YES 




REQUEST ANOTHER CREDIT CARD 

FROM BUYER 
^ 



YES 



DENY CPO 






m 



ACCEPT CPO 

660 



RG.6 



wo 98/10361 



PCT/US97/154M 



7/115 



ADD TRACKING NUMBER TO CPO 

70Q 

i 

ADO TIMESTAMP 

ZIP 

i 



CPO STORED IN CPO DATABASE 

720 



SET STATUS OF CPO RECORD TO 
"ACTIVE" 

m 



SUBJECT EXTRACTED FROM CPO 
740 

I 



CPO POSTCD IN APPROPRIATE 
SUBJECT AREA 

750 



FIG. 7 



wo 98/10361 



PCT/OS97/15492 



8/115 



CENTRAL CONTROLLER MAKES 
PERIODIC SEARCH THROUGH 

CURRENT CPO DATABASE 

800 




YES 



1 

CPO MAINTENANCE COMPLETE 
85Q 



FIG. 8 



wo 98/10361 



PCT/US97/15492 



9/115 



POTENTIAL SELLER LOGS ON TO 
CENTRAL CONTROLLER 

900 



I 



SELECTS APPROPRIATE SUBJECT AREA 

^ m 



BROWSES LIST OF AVAILABLE CPOS 

m 



SELECTS A CPO 

m. 



FULL DETAILS OF CPO THANSMmED 

TO SELLER 
940 



FIG.9 



wo 98^0361 



PCmJS97/lS4»2 



10/115 



POTENTIAL SELLER SELECTS A CPO 
FOR EXECUTION 

1000 



I 



CENTRAL CONTROLLER RECEIVES 
SELLER RESPONSE 

1010 



I 



IDENTTTY OF SELLER AUTHENTICATED 
AS WELL AS CAPACITY TO DELIVER 
GOODS ^020 



I 



CENTRAL CONTROLLER VERIFIES 
STATUS OF CPO 

JM 





NO 



SELLER RESPONSE REFUSED AND 
TRANSMITTED BACK TO POTENTIAL 
SELLER 1050 



UNIQUE TRACKING NUMBER ADDED TO 
SELLER RESPONSE 

1060 



SELLER RESPONSE STORED IN SELLER 
RESPONSE DATABASE 

1070 



FIG. 10 



PCT/US97/1S492 



11/115 



CREDIT CARD INFORMATION OF BUYER 
TRANSMfTTED TO SELLER FOR 

PR0CESIN6 jigg 



CPO IS BOUND (STATUS CHANGED TO 
■COMPLETED" AND SELLER ID ADDED) 



I 



PURCHASE CONFIRMATION 
TRANSMRTED TO SELLER 

1120 



PURCHASE CONFIRMATION 
TRANSMITTED TO BUYER 

1130 



FIG.11 



wo 98/10361 



PCTAJS97/15492 



12/115 



SELLER TRANSFERS GOODS TO BUYER 
IM 

i 



BUYER EXAMINES GOODS TO SEE IF 
THEY MEET ALL CONDmONS OF CPO 
121fl 




BUYER CONTACTS ARBITER FOR 

DISPUTE RESOLUTION 
1230 



TRANSACTION COMPLETE 

1240 



FIG. 12 



wo 98/10361 



PCTAJS97/15492 



13/115 



BUYER SELECTS PREFERRED METHOD 
OF PAYMENT 

I 



PAYMENT DATA STORED IN PAYMENT 

DATABASE 
1320 



CENTRAL CONTROLLER ESTABLISHES 
BUYER ACCOUNT 



CENTRAL CONTROLLER CONTACTS 
BANK OR CARD ISSUER TO CONFIRM 
THAT FUNDS ARE AVAILABLE 

1M 



BUYER TRANSMFTS PAYMENT DATA TO 
CENTRAL CONTROLLER 

1310 


4 


CREDIT CARD NUMBER, BANK 
ACCOUNT NUMBER 

1315 





FIG. 13 



wo 98/10361 



PCT/US97/15492 



14/115 



SELLER EICRYPTS SELLER RESPONSE 
WITH SYMMETRIC KEY 

1400 

i 



TRANSMITS SELLER RESPONSE TO 
(ANTRAL CONTROLLER 

mo. 



CRYPTOGRAPHIC PROCESSOR 
EXTRACTS SELLER ID FROM SELLER 
RESPONSE 1420 

i ~ 



LOOKS UP SYMMETRIC KEY OF SELLER 

1430 



DECRYPTS SELLER RESPONSE WITH 
SYMMETRIC KEY 

1440 



I 



SELLER RESPONSE AUTHENTICATED IF 
MESSAGE IS INTELLIGIBLE 

1450 



FIG. 14 



wo 98/10361 



PCT/USy7/lS492 



15/115 



SELLER ENCRYPTS SELLER RESPONSE 
WITH PRIVATE KEY 

m 



TRANSMrrS SELLER RESPONSE TO 

CENTRAL CONTROLLER 
1510 



CRYPTOGRAPHIC PROCESSOR 
EXTRACTS SELLER ID FROM SELLER 
RESPONSE 1520 



LOOKS UP PUBLIC KEY OF SELLER 
1530 



DECRYPTS SELLER RESPONSE WITH 

PUBLIC KEY 
154fi 

i 



SELLER RESPONSE AUTHENTICATED IF 

MESSAGE IS INTELLiGIBLE 
1531 



FIG. 15 



wo 98/10361 



PCTAJS97/15492 



16/115 



SELLER SIGNS SELLER RESPONSE 

WITH PRIVATE KEY 
160Q 

i — 



TRANSMITS SELLER RESPONSE TO 
CENTRAL CONTROLLER 



CRYPTOGRAPHIC PROCESSOR 
EXTRACTS SELLER D FROM SELLER 
RESPONSE 



LOOKS UP PUBLIC KEY OF SELLER 
1fi30 



VERFIES THE SIGNATURE USING 
SaLER RESPONSE AND PUBLIC KEY 
164Q 



SELLER RESPONSE AUTHENTICATED F 
MESSAGE IS INTELLIGIBLE 

mo. 



FIG. 16 



PCT/US97/15492 



17/115 



SELLER HASHES SELLER RESPONSE 
WTTH SYMMETRIC KEY. APPENDING 
HASH VALUE ^jqq 



I 



TRANSMITS SELLER RESPONSE TO 
CENTRAL CONTROLLER 

1710 



I 



CRYPTOGRAPHIC PRXESSOR 
EXTRACTS SELLER D FROM SELLER 
RESPONSE ^720 



I 



LOOKS UP SYMMETRIC KEY OF SELLER 

1730 



I 



HASHES SELLER RESPONSE USING 
SELLERS SYMMETRIC KEY 

1740 



SELLER RESPONSE AUTHEhmCATED IF 
GENERATED HASH VALUE MATCHES 
HASH VALUE APPENDED TO SELLER 
RESPONSE ^ 



FIG. 17 



PCT/US97/1S492 



18/115 



POTENTIAL SELLER SELECTS A CPO 
FOR COUNTER-OFFER 

im 

PREPARES COUhfTER-OFFER VWTH 
MOOFIED TERMS 

lam 

i 

AHACHES TRACKING NUMBER OF CPO 
1820 

CENTRAL CONTROLLER RECEIVES 
SELLER COUNTEROFFER AND SETS 
STATUS TO "ACnVF ^ 

I 

UNIQUE TRACKING NUMBER ADDED TO 
SELLER COUNTER-OFFER 

1840 



COUNTEROFFER STORED IN COUNTER 

OFFER DATABASE 
1850 

1 



TRANSMIT COUNTER-OFFER TO BUYER 
IM 



FIG. 18 



wo 98/10361 



PCT/US97/15492 



19/115 




NO 





YES 


CEtfTML CONTROLLER RECEIVES 


BUYER RESPONSE FROM BUYER 


J 


1920 

r 



FUNDS REMOVED FROM BUYER 
ACCOUNT AND PLACED IN SELLER 
ACCOUNTj^ 



STATUS OF COUNTER-OFFER 
CHANGED TO 'COMPLETED" 

im 

i 



PURCHASE CONFIRMATION 
TRANSMnTED TO SELLER 
1955 



PURCHASE CONFIRMATION 
TRANSMITTED TO BUYER 



COUNTER-OFFER 
TRANSMfTTED BACK TO 
SELLER 



FIG. 19 



wo 98/10361 



PCT/US97/15492 



20/115 





SELLER IMTERFACE 

m 




1 * 


4 1 



TRUSTED SERVER k- 

m 



OPERATIONS 
SERVER 



160 



BUYER INTERFACE k 

m 



BONDING AGENCY 
170 



FIG. 20 



WO9S/10361 



21/115 



PCTAJS97/I5492 




O 

UJ 

CO 

< 

JO 

o 



o 



o 
o 











EE 








O CO 




D- 




O 






CM 

CD 



wo 98/10361 



PCT/US97/15492 



RAM 



2210 



CLOCK 
2225 



DATA 
STORAGE 
DEVICE 2230 



22/115 



CPO MANAGEMENT 
CENTRAL SERVER 
•2200 



ROM 



222Q 



CENTRAL 
PROCESSING UNIT 



CRYPTO 
PROCESSOR 



220S 



COMM. 
PORT 

mo 



CUSTOMER DATABASE 



2600 



AIRLINE DATABASE 



2700 



5 



FLIGHT SCHEDULE 
DATABASE 



CPO DATABASE 



290qQ 



CPO MANAGEMENT 

PROCESS 3600 



FIG. 22 



TOCRSAND 
AIRLINES' 
^ RESERVATION 
SYSTEMS 



TO 

CUSTOMERS 
AND TRAVEL 
AGENTS 

TO SECURED 
AIRLINE 
SERVERS 



VO 98/10361 



PCTAJS97/15492 



23/115 



SECURED AIRLINE SERVER 
■ 2300 



RAM 



2310 



ROM 



2320 



CLOCK 
2325 



SECURED 
DATA STORAGE 
DEVICE 
2330 



CENTRAL 
PROCESSING UNIT 



2305 



COMM. 
PORT 

2340 



SECURED AIRLINES RULES 
DATABASE 



COUNTER OFFER RULES 

DATABASE 3iflQ 



3000 \y 

D 



C 



SECURED AIRLINE AUDIT 
DATABASE 



3m\J 



EVALUATION PROCESS 



3700 



Awrr PROCESS 



3800 



TOCPO 
MANAGEMENT 
SYSTEM 



TO 

ASSOCIATED 
AIRLINES 



FIG. 23 



wo 98/10361 



PCT/US97/I5492 



24/115 



RAM 



2410 



aocK 



2425 



CENTRAL RESERVATION 
SYSTEM CENTRAL SERVER 



ELECTRONIC 

MAIL 
PROCESSOR 

24S0 



] [ 





ROM 

2420 







CENTRAL 






PROCESSING 




COMM. 


UNIT 




PORT 


2405 




mo. 



DATA STORAGE 
DEVICE 
2430 



TOCPO 
MANAGEMENT 
> CENTRAL 
SERVER & 
AIRLINES 



FLIGHT SCHEDULE 
DATABASE 



28^0 



PRICING AND 
RESTRICTION DATABASE 



FLIGHT DATABASE 






3400 



^0 



FIG. 24 



wo 98/10361 



PCT/US97/15492 



25/115 



REVENUE MANAGEMENT 
SYSTEM 

.2500 



RAM 

251 Q 











ROM 

2520 







CLOCK 




CPU 




COMM. 






PORT 


2525 




2505 




254fi 



DATA STORAGE 
DEVICE 2530 



PRICING AND RESTRICTIONS 
DATABASE 



Js7\ 

3300 



SEAT INVEI^ORY 

DATABASE 3400 



FORCAST AND DEMAND ANALYSIS 
, DATABASE 3500 



CPO RULE GENERATION 

PROCESS 3§00 



5 



TOCRS&CPO 
MANAGEMENT 
SYSTEM 



FIG. 25a 



wo 98/10361 



PCT/US97/15492 



26/115 



>- 
cr 

if 

o o 

or 

Q. 



7=^ 



z ^ ui 

— DC 5 

Q f ^ 



>- 

if 



I— UJ I 
O CO QC 

CL til 



cr 
_ UJ 

^ y 3 s ^ 



o 



I 



LU 



tii 



CO 



AAA 



UJ 

GC 



CO 



I 



7^ 




o 
UJ p S 

< CO CO 

UJ 



l§z 

UJ on S 
o — 



CVI 
LL. 



wo 98/10361 



27/115 



PCT/US97/15492 




wo 98/10361 PCrAJS97/15492 

28/115 




wo 98/10361 



29/115 



PCT/US97/15492 



1^ 

CM 
LU 

i 



LU 



QC 
< 



PANCE 
2760 








ACCEF 
RATE 


>^ 

h~ 
CO 






CPO 








PUBLIC KEY 
2Z55I 


12347AD73E 


35627A7C9 


1829CB612 


Ol 

o 
o 


SUE JOHNSON 


BILL JOHNSON 


JOHN 
WILLIAMSON 


ADDRESS 

2745 


25 MAIN STREEET, 
CHICAGO, IL 


102 45TH ST. 
NEW YORK, NY 


9492 6TH AVE. 
NEW YORK, NY 


AIRLINE NAME 
2Z4fl 


AMERICAN 


DELTA 


UNITED 



CM 



CU CM 



CM 



wo 98/10361 



PCTAJS97/1S492 



30/115 



X Hi 



VIA 

2875 


NON-STOP 


CHICAGO 


NON-STOP 


FLIGHT 
NUMBER 
2870 


1870 


CO 
CM 
CM 


8 

CO 










AIRLINE 


AMERICAN 


AMERICAN 


UNITED 


TIME OF 
ARRIVAL 
2860 


6:00PM 


3:04PM 


7:10PM 


TIME OF 
DEPARTURE 


12:00PM 


7:00AM 


3:00PM 


O 
lO 








CO 
CM 

i 


12/12/96 


01/01/97 


03/03/97 


DESTINATION 
AIRPORT 


LOS ANGELES. CA 
(LAX) 


CO* 
CO 

2 


SAN FRANCISCO, CA 
(SFO) 


ORIGINATING 
AIRPORT 

2840 


NASHVILLE, TN 
(SNA) 


NEW YORK CITY 
(JFK). 


NEW YORK CITY 
(JFK) 




2805^ 


2810^ 


CO 

eg 



CO 
CM 

CD 



wo 98/10361 



PCT/US97/15492 



31/115 




WO9S/10361 



32/115 



PCT/US97/15492 



CM 



CO 
< 

!• 

2 

O 



PASSENGER 
NAME 
RECORD 
NUMBER 

2995 


33333 






STATUS 

m 


ACCEPTED 


PENDING 


PENDING 


OTHER 
RESTRICTIONS 

2985 




N/A 


N/A 


PRICE PER 
TICKET 

2980 


$547.01 


$188.00 


$200.00 


NUMBER OF 
PASSENGERS 
TRAVELING 

aszs 


CO 


CM 


CM 


DATES OF 
RETURN 

2970 


4/29/97- 
4/30/97 


4/30/97 


4/30/97 


/ DATES OF 
f DEPARTURE 

I 2965 


\ 4/12/97- 
\ 4/14/97 


4/22/97 


J 4/22/97 



X3 
CD 
CM 



wo 98/10361 



33/115 



PCT/US97/I5492 




WO9g/10361 



34/115 



FCTAJS97/154W 



CO >^ 

ma; 

rs z o 
or — u> 

^ 111 ^ 

si ^ 

u ^ 



NUMBER OF 

SEATS 

AVAILABLE 

3068 




m 

CM 




DATE(S) 
3066 


4/29/97 


5/1/97 


5/1/97 


FLIGHT NO. 

3064 


249X 


1209 


CO 

o 

CO 


AIRLINE 

• 3062 


AMERICAN 


AMERICAN 


AMERICAN 


RULE NUMBER 
3060 


234566 


234567 


234568 



CVJ 

to 



CO 

CO 



X2 
o 

CO 



wo 98/10361 



35/115 



PCT/US97/154W 



CO 
LU 

UJ cc 

Ij *^ 
cc ih ^ 

5 W CO 
Q CD 

LU 

CO 



o 
cc 



CO 



s 



o 

CO 
Ul 

o 



o 



o 



cc 



UJ 

QC 
< 



Q 



o 
cc 



CO 

o 

CO 



o 

CO 
CM 



CO 



LU 

o 



< < 

CO o 

o 



§5 

O 



cc 



CM 
CO 



8p 

QO 
o 



5fe 



cc 

LU 



O 
CO 



oo . 
o 

CO 



^098/10361 



36/115 



PCT/US97/15492 




wo 98/10361 



37/115 



PCT/US97/15492 



o 

^ o 

ri UJ 

oc CO 

oc < 

O 
LU 

CO 



TICKET 
BOOKED 


ANOTHER 
AIRLINE 


NO TICKET 
BOOKED 


Ui 

—I 

DC 

< 
CO 


PASSENGER 
NAME RECORD 
NUMBER 
3240 


56789 


98765 


34567 


TIME 

o235 


3:40PM 


2:00PM 


12:00PM 


DATE 
3230 


4/5/97 


4/6/97 


4/8/97 


ANSWER 
RESPONSE 

3225 


YES 


ON 


YES 


OC ^ 

CD 

ZD 

O 

Q. 

o 


2345 


2346 


2347 



g5 

2J CM 

CD er> S 



CM 
CO 

CD 



wo 98/10361 



38/115 



PCT/US97/I5492 



CO 

O 



DC 

< 

CD 

O 
CC 



g 

2 



INVENTORY 

RESTRICTION 
3350 


RETURN 
FRIDAY 


ONE STOP 


7 DAY RETURN 


>- 

DC S 

0 111 *^ 

1 E 


$40.00 


$60.00 


$20.00 


INVENTORY 

RESTRICTION 
3340 


7 DAY RETURN 


RETURN 
FRIDAY 


ONE STOP 


INVENTORY 
PRICE 


$50.00 


$75.00 


$25.00 


DATE 
3330 


4/16/97 


5/12/97 


6/3/97 


FLIGHT 
3325 


AL654 


DB120 


124C 



CO 
CO 

LL- 



CO ' 
CO 



wo 98/10361 



39/115 



PCTAJS97/15492 



o 
o 



Q 



Si 

CO 



LU 

I 

o 



TOTAL 
CAPACITY 

3450 


g 

CO 


8 

CO 


o 
c> 

CO 


g 
CO 


TOTAL SEATS 
BOOKED 

3445 




CO 


in 


CO 


INVENTORY Y 

SEATS 
AVAILABLE 
3440 




o 
o 

CM 




CM 
CM 


INVENTORY K 

SEATS 
AVAILABLE 
o435 


CM 


<o 

CO 


CO 

ir> 


CM 


DEPARTURE 
DATE 


5/15/97 


5/15/97 


5/15/97 


5/15/97 


CD ^ 

r) 

h- 
X 

o 


12345 


23456 


34567 


45678 




3405 


CO 


CO 


CO 



CO 



wo 98/10361 



PCr/US97/15492 




wo 98/10361 



PCT/US97/154W 



41/115 



CPO MANAGEMENT PROCESS asj^^ 



CUSTOMER OR TRAVEL AGENT ACCESSES CPO 
MANAGEMENT SYSTEM ^ 



I 



RECEIVE CUSTOMER INFORMATION. ITINERARY. 
PRICE AND OTHER RESTRICTIONS FROM 
CUSTOMER OR TRAVEL AGENT gggg 



CREATE RECORD OF CPO IN CPO DATABASE WITH 
RECEIVED INFORMATION AND STATUS "PENDING" 
. 3612 



DISPLAY LEGAL LANGUAGE AND AWATT 
ACKNOWLEDGEMENT TO FORM CONDITIONAL 
PURCHASE OFFER (CPO) 3616 



EXTRACT PRICE FROM CPO DATABASE AND 
CUSTOMER INFORMATION FROM CUSTOMER 
DATABASE ^gM 



I 



TRANSMfT MERCHANT ID, BILLING DESCRIPTOR 
TOTAL PURCHASE AMOUNT AND CREDIT CARD 
INFORMATION TO CREDIT CARD ISSUER FOR PRE- 
AUTHOREATION 3624 




a J TO FIG. 36b 

FIG. 36a 



REQUEST 
ANOTHER 
CREDIT CARD 
FROM BUYER 
3632 



wo 98^0361 



42/115 



PCT/US97/15492 



a ) FROM RG. 36a 



EXECUTE EVALUATION PRXESS (FIG. 17) FOR EACH AIRLINE TO 
EVALUATE CPO AGAINST SECURED AIRLINES RULES DATABASE 
3640 




TO FIG. 36c 



FIG. 36b 



wo 98/10361 



PCT/US97/15492 



c ; FROM RG. 36b 




43/115 

d) FROM FIG. 36b 



bXIHACT RECEIVED 
INFORMATION FROM 
CUSTOMER AND CPO 

DATABASES AND 
RECEIVED INVENTORY/ 
FLIGHTINFORMATION 
TO CREATE 
PASSENGER NAME 
RECORD (PNR) 
3622 

I 



TRANSMIT (PNR) TO 
AIRUNE TO ESTABLISH 
RESERVATION 

am 



TRANSMIT MERCHANT 
ID.BILUNG 
DESCRIPTOR. 
PURCHASE AMOUhrr 
AND CREDIT CARD 
INFORMATION TO 
CREDIT CARD ISSUER 

FOR PAYMENT 
3SZB 



UPDATE CPO 
DATABASE WITH PNR 
NUMBER AND 
SET STATUS TO 
■ACCEPTED" 
3^ 




e J FROM FIG. 36b 



TRANSMIT REJECTION TO 
CUSTOMER 

3690 




TRANSMIT REJECTION TO 
AIRLINES MAKING 
COUNTEROFFER 

36Sg 



UPDATE CPO DATABASE 
STATUS 70 'REJECTED* 

3m. 



UPDATE CPO DATABASE 
STATUS TO "REJECTED" 



EXECUTE AUDIT 
PROCESS (Ra 18) FOR 
EACH AIRLINE 

3686 



c 



END 



FIG. 36c 



wo 98/10361 



PCT/US97/15492 



c 



44/115 

EVALUATION PROCESS 
(CPO) 



I 



3700 



EXTRACT ORIGINATING AND DESTINATION CITES 
(O&D PAIR) FROM CPO RECORD 3705 



IDENTIFY ALL RULES PERTINENT TO EXTRACTED 
04D PAIR 2Zlfi 



I 



FOR EACH IDEhfTFED RULE. COMPARE CUSTOMER RESTRICTIONS FROM RELD 960 
THROUGH 995 OF CPO DATABASE WITH AIRLINE RESTRICTIONS FROM FELDS 1016 
THROUGH 1044 OF SECURED AIRLINE RULES DATABASE ^HS 



DOES CPO 
"^SATISFY AT LEAST ONE AIRUNE RULE?" 
3720 

,'yes 

satisfied 
rules conditioned on available 
inventory? 

_ 3725 _ 
YES 



TO FIG. 37b 



NO 



ACCESS CRS TO IDENTIFY FLIGHTS MEETING 
RESTRICTIONS OF SATKFED RULE AND CPO AND 
HAVING SEATS AVAILABLE 3730 





FIG. 37a 



TOFia37b 



TO FIG. 37b 



WO9S/10361 



PCT/USyr/15492 



45/115 



FROM FIG. 
37a 

© 



FROMRG. 
37a 



FROM FIG. 
37a 




SELECT FLIGHT WHICH MOST 
CLOSELY MATCHES CUSTOMER 
PREFERENCE OR MAXIMIZES 
CONVENIENCE 3740 



IS CPO WITHIN 
AIRLINE SPECIFIED 
TOLERANCE FOR 
sPENERATING COUNTER^ 
OFFER? 

3750 



NO 



SET RESPONSE TO "ACCEPT 
3745 



YES 



SET RESPONSE 
TO "REJECT" 

3755 



GENERATE A COUNTER OFFER 
WITH APPROPRIATE MODIFIED 
TERMS 

3760 



X 

SET RESPONSE TO "COUNTER" 

sm 



RETURN (RESPONSE, FUGHT NUMBER) 

3770 



FIG. 37b 



wo 98/10361 



PCTAJS97/15492 



46/115 



( AUDIT PROCESS ) 

1 

DECREMENT INVENTORY IN 
SECURED AIRLINE RULES 
DATABASE. IF NECESSARY 

2810 



CREATE RECORD IN AIRLINE AUDIT 
DATABASE 

3815 



c 



RETURN 



3820 



FIG. 38 



wo 98/10361 



PCT/US97/15492 



47/115 



CPO RULE GBCRATION PROCESS 39^^^ 



YES 



IS THE FLIGHT 
LIKaV TO DEPART WITH EMPTY 
SEATS? 
3910 

YES 



IS 

CURRErJTINVEI^RY 
ALLOCATION THE INmAL 
ALLOCATION FOR 
THIS aiGHT? 
3905 



NO 



NO 



ALLOCATE EMPTY SEATS TO SPECIAL 
FARE CLASS FOR CPO CUSTOMERS 

3915 



ESTABLISH APPROPRIATE MINIMUM 
FARE AND OTHER RESTRICTIONS TO 
STIMULATE SALES 3920 



UPDATE PRICING AND RESTRICTIONS, 
SEAT ALLOCATION AND FORECAST 
DATABASES 1300-1500 WITH NEW FARE 
CLASSES. ALLOCATED INVENTORY AND 
INITIAL PRICE AS APPROPRIATE 



GENERATE CPO RULE CONTAINING 
ALLOCATED INVENTORY. ESTABLIS^CD 
MINIMUM PRICE AND OTHER 
RESTRICTIONS 3930 



TRANSMIT CPO RULE TO SECURED 
AIRLINE SERVER ^ 







FIG. 39 



C 



1 



NO' 



END 



DOES 
DIFFERENCE 
BETWEEN FORECASTED 
AND ACUTAL DEMAND EXCEED 
PREDEFINED TOLERANCES 
FOR ANY FARE 
CLASS? 
3950 



YES 



ALLOCATE EXCESS CAPACITY FOR 
SALE TO C PO CUSTOMERS ^ 

T 



ESTABLISH APPROPRIATE MINIMUM 
FARE AND OTHER RESTRICTIONS TO 
STIMUUTE SALES 3960 



UPMTE PfflCING AND RESTRICTIONS. 
SEAT ALLOCATION AND FORECAST 
1300-1500 WTTH 
ALLOCATED INVENTORY AND 
ESTABLISHED PRICE 



GENERATE CPO RULE CONTAINING 
AILOCATED INVENTORY. ESTABLISHED 
MINIfcftJM PRICE AND OTHER 
RESTRICTIONS 397Q 



TRANSMfT CPO RULE 
AIRLINE SERVER 



TO SECURED 

3980 



wo 98/10361 



48/115 



PCT/US97/15492 



8 



CO 



Q 
O 



RESTRICTIONS / 


DO NOT WANT TO \ 
LEAVE U.S. \ 
TERRITORY \ 


BRITISH VIRGIN / 
ISLANDS / 


NO RESTRICTIOI^/ 


DESTINATION 
PORT 

4055 


NO CHOICE 


NO CHOICE 


NO CHOICE 


ORIGINATING 
PORT 

4050 


ST. THOMAS, 
USVI 


MIAMI, FL 


CANCUN. 
MEXICO 


COMPANION 
PASSENGERS 
404S 


MRS. JOHN 
DOE, JOHN 
DOE JR. 


ANN SMITH 


ANN SMITH 


CUSTOMER 
ID 

4040 


12345 


45231 


45231 


PRIMARY 

PASSENGER 

NAME 

4035 


JOHN DOE 


JAMES 
SMITH 


JAMES 
SMITH 


TRAVEL 

AGENT 

NUMBER 
403C 


i 


2648 


2648 


DATE 
4025 


4/20/97 


4/21/97 


4/21/97 


CPO 
NUMBER 

4020 


23456 


123457 


23458 



u> 

8 



CO 

o 



VfO 98/10361 

PCTAJS97/15492 

49/115 




wo 98/10361 



PCT/US97/15492 



50/115 



o 
o 



U-l 

i 

CO 
UJ 



UJ . 



o 

UJ 

a: 

CO 



departure/ 

DAY OF / 
WEEK^ 


TUES- \ 
THURS \ 


... ) 


TIME(S) OF 
DEPARTURE 

1122 


N/A 


Q. 
• 

< 


DATE(S)OF 
DEPTARTURE 
112fl 


10/1/97- 
10/31/97 


4/1/97- 
5/31/97 


CRUISE 
NUMBERS 
4118 


N/A 


N/A 


ORIGINATING 
PORT 

4112 


ST. THOMAS 


ST. THOMAS 


RULE 
NUMBER 
4110 


lO 

GO 




CO 

to 


GO 
CO 

to 




4102^ 


o 
5? 



ADVANCE PURCHASE 
REQUIREMENTS 

4144 


2 MONTHS 


1 

o 


INVENTORY 
RESTRICTIONS OR 
AVAILABILITY ...^ 
4112i 


LUXURY N/A 


ALL AVAILABLE 


MINIMUM 
PRICE 
4140 




$630 


3= S o 


OJ 


eg 


LENGTH 
OF HAUL 
4136 


N/A 


N/A 


NUMBER OF 

PASSENGERS 

TRAVELING 

4134 


AT LEAST 2 


CM 


U ^ UJ 

oc o S 


TUES.- 
THURS. 


•. CO 

z cc 

O 3 


TIMES OF 
RETURN 
4130 


N/A 


11AM-2PM 


/dATE{S)OF 
/ RETURN 

1 m. 


\ 10/1/97- 
\ 10/31/97 


1 4/1/97- 
/ 5/31/97 



CD 



PCT/US97/154W 



51/115 



START POST-SELL MULTI-BIND EVALUATION 
PROCESS 



r 



4200 



I 



INSTRUCT ACCEPTING OPERATORS TO PROVIDE POST-SELL 
INFORMATION 



4210 



RECEIVE POST-SELL INFORMATION FROM ACCEPTING OPERATORS 
4220 



TRANSMIT OR MAKE AVAILABLE THE POSTAL INFORMATION TO THE 

CUSTOMER 

^ 



RECEIVE CUSTOMER DECISION REGARDING ACCEPTING 
OPERATOR 



C 



RETURN 



4250 



FIG. 42 



WO9S/10361 



52/115 



PCTAJS97/15492 




wo 98/10361 



PCT/US97/15492 



53/115 



( EXCLUDED SELLER CPO EVALUATION PROCESS 


) 


1 




RECEIVE CPO FROM CUSTOMER AND STORE IN 




CPO DATABASE 


m. 


1 


READ SPECIRED OPERATOR'S DATA OF THE CPO 




4410 


i 


ACCESS OPERATOR DATABASE 




4415 



r 



4400 



YES 




NO 



EXTRACT THE CPO INFORMATION 
AND TRANSMfT TO THE SPECFIED 
AND EXCLUDED 
OPERATORS 443Q 

1 



CONTINUE CPO MANAGEMENT 
PROCESS 

4425 



RECEIVE COUhfTER OFFERS FROM THE EXCLUDED 

OPERATORS 4435 

i 



CR^TE NEW RECORD IN OPERATOR OFFER DATABASE FOR 
EACH NEW OFFER 44^ 

1 



PRESENT OPERATOR OFFERS TO CUSTOMER 



TO FIG. 44b 

FIG. 44a 



4445 



wo 98/10361 



PCT/US97/1S492 



54/115 

A) FROM R6 44a 



YES 



DOES CUSTOMER 
'ACCEPT ANY OF THE COUNTER" 
OFFERS BEFORE CPO IS ACCEPTED BY 
A SPECIFED 
OPERATOR? 
4450 



NO 



CANCEL ORIGINAL CPO AND 
CHANGE STATUS TO CANELLED 

4460 



CONTINUE CPO MANAGEMENT 
PROCESS 

4455 



CHANGE THE STATUS OF ACCEPTED COUNTER OFFER TO 
ACCEPTED, STATUS OF THE OTHER COUNTER OFFERS TO 



REJECTED 



4465 



CONTINUE WITH CPO MANAGEMENT PROCESS 



4470 



FIG. 44b 



WO9a/10361 



55/115 



PCT/US5>7/15492 



o 

a. 

o o 



o ^ 

DC lU Q 
I— -J <c 
cn ^ u. 

— > LU DC 
Q CO UJ 



o 





LU 


o 


FACI 
4806 


>- 


cr 


GC 








co 








o 


cc 


z 


UJ 

—J 




_i 




UJ 




CO 




MTO 98^0361 



PCT/US97/15492 



RAM 
4610 



CLOCK 



4625 



OPERATING 
SYSTEM 

4650 



56/115 



CENTRAL 
CONTROLLER 4600 





ROM 
4620 







CPU 
4605 



PAYMENT 
PROCESSOR 

4660 



DATA STORAGE 
DEVICE 4630 



BUYER 
DATABASE 



4900 



1) 



^ SELLER 




^ DATABASE 


aiQo(J 



PACKAGE CPO 
DATABASE 



5100 



COMPONENT CPO 
DATABASE 



MARKET PRICE 
DATABASE 



5300 



3 
i) 
8 



PACKAGE CPO P0STB«3 
PROCESS 5500 



PACKAGE CPO MONITORING 
PROCESS 5600 



TO EFT 
NETWORK 



NETWORK 
INTERFACE 
4680 



TO BUYERS 
AND SELLERS 



FIG. 46 



wo 98/10361 



PCmJS97/15492 



57/115 



SECURED AIRLINE SERVER 



RAM 



CLOCK 
4725 



SECURED 
DATA STORAGE 
DEVICE 
4730 



4710 



ROM 



4720 



CENTRAL 
PROCESSING UNIT 



4705 



COMM. 
PORT 

4740 



SECURED SELLER RULES 

DATABASE 5000 



COMPONENT CPO RULE 
EVALUATION PROCESS SOQ 



5 



4700 



TO PACKAGE 

CPO 
MANAGEMENT 
SYSTEM 



FIG. 47 



wo 98/10361 



PCT/US97/15492 



58/115 



VIDEOMONITOR 
4850 



VIDEO 
DRIVER 
4860 



CLOCK 
4825 



RAM 



4810 



ROM 



4820 



CPU 

4808 




COMM. 
PORT 
4840 





DATA STORAGE 
DEVICE 4830 



MESSAGE DATABASE 



8 



5 



BUYER OR SELLER 
l^frERFACE 4800 



TO CENTRAL 
CONTROLLER 
4600 



INPUT 
DEVICE 
4870 



FIG. 48 



wo 98/10361 



59/115 



PCT/US97/15492 



o 
o 



< 

CD ^ 



CD 



CO 
UJ 

m 



O 

Q. 
O 



o tn 
5i 



UJ 2 
oc o 
o o 
o 
< 



CO 
CO 

tu 

GC 
O 
O 

<c 



UJ 




CM 
CM 


CO 
CO 


22-22 










CM 
CM 






• 

CM 




1^ 

CM 


CO 



CO 



CO 



CM 
CM 

Si 



tu 



X 

o 



CO 



CM 
CD 



CO 

UJ 

—J 
CI. 



>- 

X 

I- 
cr 
< 

S3 

UJ 

i 



r> CD in 



CD 



o 

^ CD 



wo 98/10361 



60/115 



PCT/US97/1S492 



OJ 




CO 














cr 




LU 


Q 


1 

1 


CC 


LU 


LU 


CO 










CO 





CD 
Z 

S CC 
O 

< CD 

O 2: 

a. 

O 



Q 

DC 



CO 



CM 

o 



CO 

uu 



CC 

< 

i 

CC 



CO 
CO 

co 



Q_ 



CO 



CC 



oo 



CM 





CM 




CO 






1^ 


oo 


o> 


CO 


o> 


O 


CL 


Ci_ 


OL 




2 




ERTZ 


;rato 


LTON 


X 


LU 

a: 






CO 




o> 


GO 




CM 






a> 


CO 




CM 








QO 





S 5 5 g g S 

m in to to to to 



o 
to 

CD 



wo 98/10361 



61/115 



PCTAJS97/15492 



LU 

CO 

i 

I 

UJ 

I 



POSTING DATE / 

sissf 


8/1/97 \k 


8/15/97 


ION 






PER ALLOCAT 
MARGIN 

PERCENTiM 


O 
lO 


%os 


9 o 


o 
o 
o> 
<o 


$1800 


PA 






REMAINING 
MARGIN 
S140 


s 


o 
o 

04 
<^ 


MARGIN 
FACTOR 
5135 


5^ 
O 


o 


ORIGINAL 
PACKAGE CPO 
PRICE 513fi 


$1,000.00 


$2,000.00 


STATUS 


33.3% 
COMPLETE 


ACTIVE 


PACKAGE 
CPO NUMBER 


P001 


P002 



7^ 




CM 
CM 
CM 
CM 




o ^ 

CO z 



o 



J2 

LU 

o 

o 
o 




CO ^ 

DC O 



CC LU 



X O 5 

CO D- Q 




CO 

< 
o 



S3 



^1 



h- - 
CO ^ 
OC o 



f S3 
o<2o 

S LU 



LU 

CC 
QC 



§ 



o 



LL. 



X o 



o 

O 
CO 



CO 
CO 



o 



o 
to 



wo 98/10361 



62/115 



PCT/US97/15492 




wo 98/10361 



63/115 



PCT/US97/15492 



o 

UJ 

a. 

LU 



UJ 

Q 
> 



CO 



UJ 

ZD 

a 



O 

CM 



^ oc 

^ LU 
LU CO 



CO 
CO 

o 

cc 



UJ 



oc 

I- o 

Z 
=> 
O 

OC 



o 

CO 



Oo: 

^ UJ 
UJ CO 



UJ 

> 
o 

DC Z 



CO 
CO 

o 



CO 
00 



cc 

^ CO 

cc ^ 

H- O 



O 
DC 



O 

o> 

CVJ 



^ UJ 

UJ CD 

UJ 

> 

CO O 

oc 2: 



X 

o 
< 
o 
o 



UJ 

gc 

< CO 
o »- 



o 

DC 



o 



Ooc 

^ UJ 
LU CD 

UJ -s; 



> 
O 

OC z 



DC 

r> 

X 



Ul 

GC 

OC 
< 

o 



o 
CVJ 



Occ 

^ UJ 
LU CD 



CO O 

OC z 



UJ 
M 

CO 
■ 



UJ 

CC 

oc 
< 
o 



oc 

^ LU 
LU CD 

^ UJ 

CO O 
CC z 



O 

<: 

OL 

o 
o 



UJ 
DC 

OC 

< 
o 



o 
to 



LU 

Ul CD 

yj s 

LU 

> 
CO o 



CO 



o 



^ UJ 



< 
IS 
oc 
o 



o 

CO 



^ LU 

LU CD 

^ Ul 

oc :^ 



::e 
o 

o 
o 



Si 



^ " ~ in o u 
in in u 



CO 

in 



CO 

in 



CO 
iO 



o 



lO 

in 



CO 
LO 

LL. 



wo 98/10361 



PCT/US97/15492 



64/115 



O 
O 

s 

UJ 
CO 



2 

CO 



cr 

UJ 



CC 

< 
o 

UJ 

CC 

o 

UJ 

CO 



UJ _^ 
DC "* 

t: u- S 

rr: >; UJ 
5j g y 


TUES- \ 
THURS \ 




TIME(S) OF 
DEPARTURE 
5422 


V/N 


11AM-2PM 


DATE(S)OF 
DEPTARTURE 
5420 


10/1/97- 
10/31/97 


4/1/97- 

5/31/97 


FLIGHT 
NUMBERS 
5418 


V/N 


i 


CONNECTION 
RESTRICTIONS 


V/N 


THRU 
CLEVELAND OR 
PinSBURG 


DESTINATION 
CITY 
5414 


ORLANDO, FL 
(MCO) 


CHICAGO. IL 
(ORD) 


ORIGINATING 
CITY 

5412 


NEWARK, NJ 
(EWR) 


NEW YORK. 
NY (JFK) 


RULE 
NUMBER 
5410 


45685 


45687 



CM 
O 



ADVANCE PURCHASE 
REQUIREMENTS 


WITHIN 21 DAYS OF 
FLIGHT 


7-21 DAYS PRIOR TO 
FLIGHT 


INVENTORY 
RESTRICTIONS OR 
AVAILABILITY ^ 


K INVENTORY 
ONLY 


Q OR K INVENTORY 
ONLY 


2 21 

13 lU a 

s o SI 


165.00 


50,00 








UJ ^ 


N/A 


V/N 


5: 






LENGTH 
OF HAUL 
5436 


N/A 


N/A 


NUMBER OF 

PASSENGERS 

TRAVELING 

5434 


AT LEAST 2 


Csj 


pi >_ UJ 
□ ^ UJ 


TUES.- 
THURS. 


MON.- 
THURS. 


TIMES OF 
RETURN 
5430 


N/A 


< 


/dATE(S)OF 
RETURN 
5426 


\ 10/1/97- 
\ 10/31/97 


1 4/1/97. 

/ 5/31/97 



as 
CD 



wo 9a/10361 



PCT/US97/15492 



65/115 



o 

lO 

s 

UJ 
CO 

Q 



DC 

o 



ADVANCE PURCHASE 
REQUIREMENTS 
5490 


WITHIN 7 DAYS OF 
CHECK-IN 


WITHIN 21 DAYS OF 
CHECK-IN 


WITHIN 28 DAYS OF 
CHECK-IN 


MINIMUM 
PRICE 
5485 


$350.00 


$700.00 


$500.00 


CHECK-OUT DAY 
OF WEEK 
5480 


SATURDAY 


MONDAY 


FRIDAY 


CHECK-IN DAY 
OF WEEK 
5475 


THURSDAY 


MONDAY 


MONDAY 


■NGTHOF 
STAY 


3 DAYS 


7 DAYS 


5 DAYS 


1 








SITE 




< 


o < 
a o 


HOTEL 

it 


TAMF 
FLOR 


is 
It. 


3 o 


RULE 
NUMBER 
5460 


22233 


22234 


22235 



7^ 



IT) 

d 



CO 

in 



WO9S/1036i 



PCT/USW15492 



, 5500 

66/115 



< , J 

{ PACKAGE CPO POSTING PROCESS j 



RECEIVE CONDmONAL PURCHASE OFFER (CPO) FOR A PACKAGE OF 
COMPONEm" GOODS/SERVICES FROM BUYER 5§M 

1 — 



RECEIVE CONDITIONS INCLUDING DESCRIPTION FOR EACH COMPONENT 
GOOD/SERVICE FROM BUYER 

SS10 

i 



RECEIVE PRCE AND EXPIRATION DATE FOR PACKAGE CPO FROM 

BUYER K15 

i ~ 



ADD LEGAL LANGUAGE TO FORM PACKAGE CPO 



GENERATE PACKAGE CPO NUMBER 

5525 



I 



ENTER PACKAGE CPO INFORMATION INCLUDING BUYER ID NUMBER, 

PACKAGE CPO PRICE. PACKAGE CPO EXPIRATION DATE AND 
CONDITIONS OF GOODS/SERVICES l^f^O PACKAGE CPO DATABASE 

5530 

i 

aU-CULATE MARGW BY MULTIPLYING PACKAGE CPO PRICE BY MARGIN 



TO FIG. 55b 




FIG. 55a 
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ENTER MARGIN IN "REMAINING MARGIN" FIELD OF PACKAGE CPO 

DATABASE 5540 



CALCULATE ADJUSTED CPO PRICE BY MULTIPLYING ORIGINAL PACKAGE 
CPO PRICE BY MARGIN FACTOR AND ENTER INTO PACKAGE CPO 

DATABASE 
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SET STATUS OF PACKAGE CPO TO 'ACTIVE" IN "STATUS" FELD OF 
PACKAGE CPO DATABASE 
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RETRIEVE MARKET PRICES OF COMPONENT GOODSSERVKJES 
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CALCULATE MARKET PRICE OF PACKAGE CPO BY ADDING INDIVIDUAL 



MARKET PRICES OF COMPONENT GOODS/SERVICES 
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CALCULATE INDIVIDUAL CPO PRICES FOR EACH COMPONENT OF 

PACKAGE 
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GENERATE A CPO NUMBER FOR EACH COMPONENT CPO 
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CREATE A NEW RECORD FOR EACH COMPONENT CPO IN COMPONENT 
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PROVIDE COMPONENT CPOS TO NONflULES BASED SELLERS AND 
EXECUTE RULES EVALUATHDN SUBROUTINE (Fia 12) FOR RULES BASED 
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END 
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RETREVE BUYER IDENnFICATION 
INFORMATION FROM BUYER 
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NAME. ADDRESS. AND CREDIT 
CARD ACCOUNT 
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CENTRAL CONTROLLER ADJUSTS 
•STATUS" RELD OF PACKAGE CPO 
DATABASE TO REFLECT PERCFENTAGE 
OF PACKAGE CPO THAT IS PRE-BOUND 

5620 



CENTRAL CONTROLLER 
COMMUNICATES TERMINATION OF PRE- 
BIND AGREEMENTS WITH POTENTIAL 
SELLERS ^ 



CENTRAL CONTROLLER RETRIEVES 
"TOTAL POSTING DURATWN" FROM 
PACKAGE CPO DATABASE AND 
MULTIPLIES IT BY "POSTING TIME 
REQUIRED FOR EACH ALLOCATION" IN 
PACKAGE CPO DATABASE 

5625 



CENTRAL CONTROLLER 
COMMUNICATES EXPIRATION OF 
PACKAGE CPO TO BUYER 

5640 
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END 
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BEEN ACTIVE FOR THE POSTING 
TIME REQUIRED TO ALLOCATE 
MARGIN? 
5630 
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TO FIG. 56a 



TO FIG. 56c 



FIG. 56b 



wo 98/10361 



PCT/US97/15492 



71/115 



FROM no. 

56b 



CALCULATE PERCENT COMPOSITION OF REMAINING ACTIVE 
COMPONENT CPOS REUTIVE TO EACH OTHER BASED 
ON PRICE 
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RETRIEVE "PER ALLOCATION MARGIN PERCENTAGE* FROM PACKAGE 

CPO DATABASE 

^ 



I 



CALCULATE AMOUNT OF MARGIN TO BE ALLXATED TO REMAINING 
ACTIVE COMPONENT CPOS BY MULTIPLYING PER ALLOCATION MARGIN 
PERCENTAGE BY REMAINING MARGIN AMOUNT IN "REMAINING MARGIN" 
FELD OF PACKAGE CPO DATABASE 



DETERMINE HOW TO APPLY AUOCATABLE MARGIN BY MULTIPLYING 
PRICE PERCENTAGES OF REMAINING ACTIVE COMPONENT CPOS AS 
DETERMINED IN STEP SSZS BY ALLOCATABLE MARGIN 
AMOUNT 5684 



CENTRAL CONTROLLER APPLIES ALLOCATABLE MARGIN TO REMAINING 
ACTIVE PRE-BIND CPOS IN APPROPRIATE PERCENTAGES „oc 



ADJUST REMAINING MARGIN BY SUBTRACTING ALLOCATABLE MARGIN 
FROM REMAINING MARGIN AND ENTERING IT INTO "REMAINING MARGIN' 
HELD OF PACKAGE CPO DATABASE 

ODOO 
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POST ADJUSTED COMPONENT CPO PRICES BY UPDATING THE PRICE 
RELDS IN THE PACKAGE CPO DATABASE CORRESPONDING TO THE 
COMPONENT PRE-BIND CPOS 5590 
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IDENTIFY ALL RULES PERTINENT TO COMPONENT CPO IN 
SECURED SELLER RULES DATABASE 5710 
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FOR EACH IDEWTFIED RULE. COMPARE CUSTOMER 
RESTRICTIONS SET FORTH IN COMPONENT CPO TO 
SELLER RESTRICTIONS IN CPO RULE 5720 




NO 





YES 






RETRIEVE COMPONETfT CPO NUMBER FROM COMPONENT 


CPO DATABASE 




5740 



ENTER COMPONENT CPO NUMBER INTO "CPO TRACKING 
NUMBER" FELD OF SELLER DATABASE 

5750 
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CHANGE "STATUS" FELD IN COMPONENT CPO DATABASE 
FROM "ACTIVE" TO "PRE-BIND COMPLETED" 

5760 
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END 
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c 



CPO MANAGEMENT PRXESS 



3 r 



RECEIVE CALL FROM CALUNG PARTY 


6505 




r 


EXTRACT ANI NUMBER OF INCOMING CALL 


6510 



I 



CREATE NEW RECORD IN CUSTOMER DATABASE AND STORE ANI AS 

CUSTOMER ID 



6515 



EXECUTE WRU OR OTHER CUSTOMER INTERFACE PROCESS STORED IN 
DATA STORAGE DEVICE TO RECEIVE PARAMETERS OF CONDFTIONAL 
PURCHASE OFFER FROM CUSTOMER INCLUDING NUMBER TO BE 
CALLED. SPECIFIED PRICE, TIME LIMITATIONS AND OTHER 

RESTRICTIONS §§25 



STORE PARAMETERS IN CPO DATABASE IN RECORD INDEXED BY 
CUSTOMER ID 



A )T0FIG.65b 



FIG. 65a 



wo 98/10361 



PCT/US97/15492 



82/115 

A j FROM FIG. 65a 




PROVIDE CPO TO CARRIERS 

6535 



RECEIVE RESPONSE FROM 

CARRIER 
£540 





NOTIFY CUSTOMER THAT CPO HAS 
BEEN REJECTED 

6550 



CHANGE STATUS TO REJECTED 

655S 



c 



I 



END 



6560 



PROVIDE FULL CUSTOMER RECORD 

TO ACCEPTING CARRIER TO 
COMPLETE CALL IN ACCORDANCE 
WITH CPO fi§70 



I 



CHANGE STATUS TO ACCEPTED 

6575 
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END 
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IVRU PRXESS 



I 



WRU PROMPTS CALLER FOR THE NUMBER HE WISHES TO CAa 

6610 



I 



WRU CAPTURES RESPONSE DATA AND TRANSMITS TO CPU 



6620 



I 



IVRU PROMPTS CALLER FOR THE PRICE HE WISHES TO PAY FOR THE 
CALL AND THE MANNER IN WHICH THE CPO WILL BE BOUND 

6630 



IVRU CAPTURES RESPONSE DATA AND TRANSMITS TO CPU 



6640 



IVRU PROMPTS CALLER FOR ANY OTHER RESTRICTIONS OR 
SPECIFICATIONS INCLUDING: A TIME LIMfT FOR THE CALL. THE DESIRED 
CARRIERS TO WHICH THE OFFER WLL BE SUBMITTED AND A TIME LIMIT 
FOR HOW LONG THE OFFER SHOULD BE PENDING 



I 



IVRU CAPTURES RESPONSE DATA AND TRANSMITS TO CPU 



6660 



TO FIG. 66b 



FIG. 66a 
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IVRU INSTRUCTS CALLER TO HANG UP AND WAIT FOR 
CARRIER RESPONSE 

6670 







END 
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FIG. 66b 
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FIG. 69 
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